Security
S3 access key security: protect the credential that protects the bucket
An S3 access key is an application credential, not a harmless identifier. The access half can often appear in logs, but the secret half must be treated like a production password because anyone who obtains both can exercise whatever actions the policy allows.
Give each workload its own identity
Do not copy one access/secret pair into every server and backup job. Separate identities make it possible to revoke one compromised system without interrupting every application using the account.
A per-service identity also produces clearer audit evidence because requests can be attributed to a narrower operational purpose.
Scope actions and resources
A backup writer may need object upload, multipart operations, listing and restore reads for one bucket. It normally does not need to create projects, enumerate every bucket in the provider account or change another service’s policy.
Start with the smallest practical action set and expand only when a real client operation fails for a understood reason. Broad administrator policies are easier to deploy and harder to contain.
Keep secrets out of source control
Store production secrets in a secrets manager, protected environment file or application-specific credential store with restrictive filesystem permissions. Do not paste them into Git repositories, issue comments or screenshots.
CI systems should inject credentials at runtime. A secret that has entered a public or shared log should be rotated even if the log is later deleted.
Design rotation before the first incident
A safe rotation creates a replacement credential, updates the workload, verifies new requests, then revokes the old credential. Deleting the old key first can turn a security improvement into an outage.
Keep the access-key identifier in service state so the control plane can prove which credential should be revoked without storing the secret again.
Practice emergency revocation
Know how to disable a user or delete credentials independently of deleting the bucket. Suspension and credential revocation should preserve retained data while stopping customer requests.
An incident runbook should define who can trigger revocation, how the customer receives a replacement and what evidence confirms that the old key no longer works.