Security
Least-privilege S3 policies for backup and application workloads
Least privilege is most useful when it is concrete. For S3-compatible storage, that means identifying the bucket and operations a workload really needs, then proving both allowed actions and denied cross-service actions.
Separate the provisioning identity from data identities
The control plane may need permission to create projects, buckets, users and quotas. A backup agent does not. Keep those identities separate so compromise of a customer workload cannot reconfigure the provider account.
Customer credentials should begin below the administrative layer and should never be able to create another tenant or alter provider billing.
Scope resources before actions
First decide which bucket or object prefix the workload owns. Then grant only the actions needed against that resource boundary.
A policy that allows limited actions against every bucket can still reveal or affect unrelated tenants. Resource scope and action scope need to work together.
Map actions to the client workflow
Multipart upload requires more than a simple object PUT. Restore tools may need listing, HEAD requests or version reads. Presigned upload services may need signing permissions in the application but no direct public bucket access.
Use protocol traces or documented client behavior to refine the policy from the required operations and avoid broad wildcards as a default fix.
Test explicit denials
A launch test should attempt to list another tenant, read a foreign object and perform an administrative operation. Those requests must fail even if a bucket name is known.
Negative testing is stronger evidence than reviewing a policy document because it confirms how the backend actually evaluates the effective permissions.
Re-review policy after feature changes
Adding versioning, object lock, replication or lifecycle functions can change required actions. Update the policy deliberately and keep new administrator capabilities out of customer identities.
The smallest policy that supported last year’s client may be incomplete today; the broadest policy that avoids support tickets today may be unsafe tomorrow.