Security and privacy

How Portal holds your provider credentials, what it can do in your cloud accounts, and what it keeps.

Warnings and limits

A connection lets Portal start and end machines in your cloud account, within the access you gave it. Prefer a role or a federated credential: nothing that could be replayed is stored.
Jobs on your own machines run as the user who installed Portal's agent, with that user's access.
Checkpoints are encrypted with a key of each job's own. Outputs and logs are kept in Portal's storage without that per-job encryption.
Never paste a token or a secret into a chat or a command line. Portal never asks for one there.
Portal keeps outputs 7 days, logs 30 days and checkpoints as Checkpoints and retention says.

Your provider credentials

Roles and federation first. For AWS, Portal assumes a role in your account with an ExternalId bound to your workspace; for Azure, a federated credential trusts Portal's identity; for Google Cloud, a keyless binding where Portal offers one. No secret that could be replayed is stored for these.
Keys and tokens are sealed. An access key, a service account key, a client secret, a Modal token or a Lambda API key is encrypted with your workspace's own key when it is saved, and is never returned by any API, the console or the CLI.
Values are read privately. portal connect and portal secrets set read secret values from a file, an environment variable or a hidden prompt, never from a command-line argument. Coding tools pass the path of a secrets file or the names of environment variables, so values never pass through the model.
Verified on save. Portal checks a connection with the provider when you save it, and keeps the previous one if the check fails.

What Portal can do in your account

Only what its job needs, on resources it made:

start machines, tagged soma:managed=true (on Google Cloud, the label soma-managed=true), and terminate only tagged machines;
read prices, instance types and, on AWS, your EC2 vCPU quotas and Cost Explorer totals;
on AWS, work only in security groups it made, in VPCs portal connect aws --from-cli tagged, and launch only public images with no snapshot attached.

It never deletes your data, never touches machines it did not start, never changes your account's access or quotas, and never powers off a machine you enrolled. See AWS.

Every machine has a hard stop, which Portal keeps renewing while the job runs. If Portal stops renewing it, the machine ends itself. Portal also ends machines past their lease, and portal audit lists everything Portal runs on every connection.

Your code and data

The project you upload leaves out credential files by default: .env files, private keys, cloud credential files and directories, and .git. See what is uploaded.
Checkpoints are encrypted on the machine, with a key of the job's own, before they are stored, and verified when they arrive.
Every transfer uses TLS.
Outputs and logs are stored in Portal's storage for the times on Checkpoints and retention, then deleted.

Signing in

Portal uses your Clusy account. Sensitive actions need a Clusy sign-in from the last 5 minutes. The CLI and coding tools get credentials of their own through a browser approval; you can revoke each in the console's Settings, Agents. Agent tokens never hold admin access.

These docs

These pages are static files served by Portal. They hold no user data, set no cookies, and load nothing from any other site.

Report a security issue

See Clusy's security page at clusy.io/security.