Skip to main content
A storage credential is an access key pair (accessKeyId + secretAccessKey) scoped to one bucket with a role. Hand it to any S3-compatible client to read or write that bucket. Credentials are issued per bucket, not per account. That keeps the blast radius tight: a leaked key only exposes the bucket it was issued for, and revoking it doesn’t affect any other bucket.

​
Roles

Roles are immutable; to change a credential’s role, rotate to a new one with the role you want and revoke the old one.

​
Create a credential

​
From the dashboard

  1. Open the bucket’s detail page.
  2. Go to Credentials → New credential.
  3. Pick a role (ReadOnly or Editor).
  4. Click Create.
  5. Copy both accessKeyId and secretAccessKey right away. The secret is shown once; after you close the modal, you can rotate or delete but you can’t view it again.
  6. Store the pair in your secret manager, your CI secret store, or a .env file outside source control.
New credential dialog with the role selector for ReadOnly or Editor, the issued access key id, and the one-time secret access key with a copy button

The New credential dialog with role selector and the one-time secret reveal.

The dashboard lists existing credentials with their role, creation date, and status (active or revoked). The secret is never displayed after creation.

​
Use the credential

Pass the pair to any S3 client along with the bucket’s endpoint and region:
See Working with objects for SDK examples in Node, Python, and the AWS CLI.

​
Rotate a credential

Rotating issues a new access key pair under the same role and revokes the old one in the same step. Use this when:
  • A key may have been exposed.
  • You’re handing off ownership (the previous holder shouldn’t keep access).
  • You have a scheduled rotation policy.

​
From the dashboard

  1. Open the bucket’s Credentials tab.
  2. Click Rotate next to the credential.
  3. Confirm.
  4. Copy the new accessKeyId and secretAccessKey immediately. The old pair stops working the moment rotation completes.
No grace period. Rotation invalidates the old key the instant the new one is issued. Update every consumer (app config, CI secrets, deployed services) before rotating, or stage the rotation so the new key is in place first.

​
Revoke a credential

Revoking permanently disables a credential. It can’t be re-enabled; create a fresh one if you need a key again.

​
From the dashboard

  1. Open the bucket’s Credentials tab.
  2. Click the overflow menu on a credential and choose Delete.
  3. Confirm.
A revoked credential’s row stays in the list with status revoked for audit purposes.

​
Security recommendations

  • Issue one credential per consumer. Don’t share a single pair across services; one pair per app / CI job / external integration makes rotation and revocation surgical.
  • Default to ReadOnly. Use Editor only where writes are actually needed. A typical setup has one Editor credential for the upload path and many ReadOnly credentials for consumers.
  • Rotate on schedule. Quarterly is a reasonable cadence for production credentials, more often if your compliance posture demands it.
  • Never commit credentials. .env, secret managers, CI secret stores; not source control, not chat threads.
  • Treat dashboard access as administrator-level. Anyone who can see the dashboard can issue or rotate credentials. Lock down team membership accordingly and require two-factor authentication.
Use Brimble environment variables for app-side keys. If your application runs on Brimble, store the storage credential in the project’s env vars instead of baking it into the image. You get encrypted-at-rest storage, per-environment scoping, and one-click rotation.

​
Troubleshooting

InvalidAccessKeyId. The accessKeyId doesn’t match any active credential for the bucket. Check the value, and confirm the credential hasn’t been rotated or revoked. SignatureDoesNotMatch. The secretAccessKey doesn’t match, or the region passed to the S3 client doesn’t match the bucket’s region. Re-check both. AccessDenied on PutObject / DeleteObject. The credential is ReadOnly. Issue an Editor credential for the writer, or rotate the existing credential under the new role. Lost the secret. You can’t recover a secret after the create modal closes. Rotate to a new pair, copy the new secret immediately, and revoke the old one.

​
Next steps

  • Working with objects, wire the credential into an S3 SDK or CLI.
  • Buckets, CORS rules for browser-driven access with these credentials.
  • API keys, Brimble’s account-level API key for the Brimble API itself (separate from storage credentials).
Last modified on May 31, 2026