Credentials & scopes

There are no bucket policies here. Access is a property of the credential — which is simpler, and different enough to be worth five minutes.

What a credential is

An access key id starting PCAK, and a secret. It signs requests with Signature Version 4, exactly like an AWS key, and any S3 client accepts it without modification.

Your PopCloud credential is not an infrastructure key. It proves who you are at the edge; PopCloud signs the storage request internally. That split is why revoking your credential is instant and total, and why permissions stay simple across regions.

The secret is shown once

At creation, and never again — we do not store it in a form we can show you. If it is lost, rotate the credential.

Scope

Every credential carries three limits, all enforced at the edge on every request. Together they do the job that IAM policies and bucket policies do on AWS.

Limit	Options	Use it for
Permissions	`read`, `write`, `delete` — any combination	A CDN or a public site gets `read`. A backup agent gets `read` and `write` but not `delete`, so it cannot destroy its own history.
Buckets	Every bucket, or an explicit list	One credential per service, scoped to the bucket that service owns. A leak stays inside one bucket.
Expiry	A timestamp, or none	Contractors, one-off migrations, CI jobs — anything that should stop working on its own.

A request outside the scope is refused with AccessDenied before anything is read or written. A read-only credential attempting a write sees exactly that.

Rotating without downtime

Rotate the credential. A new key and secret are issued immediately.
The old key keeps working for a 24-hour overlap, so you can deploy the new one without a synchronised restart.
The old key stops at the end of the window, automatically.

If you need the old key dead now — a leak rather than a routine rotation — revoke instead. Revocation takes effect within a minute everywhere, and there is no overlap.

How to divide them up

One credential per service, not per person. When something needs to be revoked you want to know exactly what breaks.
Scope down rather than up. A credential that can only read one bucket is a smaller incident than one that can delete all of them.
Never ship one to a browser. Sign on the server and hand out a presigned URL — see access.

For automation

Storage credentials authenticate to the S3 endpoint only. They carry no authority over the control plane, so creating buckets or minting credentials from a script is a different question:

Friction

The control-plane API has no machine token

You’ll see: There is no API key to give a CI job or a Terraform provider that needs to create a bucket, mint a credential, or set CORS rules.
Why: The control plane authenticates people: an access token from `POST /v1/auth/login` plus a refresh cookie. Storage credentials (PCAK…) authenticate against the S3 endpoint only — they carry no control-plane authority.
Instead: For automation, log in from the job with a dedicated user's credentials, hold the access token for the run, and refresh if the run outlives it. Do not embed a human's long-lived session in shared CI. Bucket and credential creation is otherwise a one-time setup step you can do in the dashboard.