/// CONCEPTS / PERMISSIONS

Permissions

storafleet acts with exactly the permissions you grant for each Fleet — scoped to that one bucket. The recommended IAM Role method sets a least-privilege policy for you; with access keys you attach the policy yourself.

How access works

Each Fleet connects to one bucket. There is no account-wide discovery — storafleet never needs s3:ListAllMyBuckets. A role-based Fleet is assumed via STS for short-lived credentials; a key-based Fleet uses the IAM user's keys directly.

Minimum required permissions

These actions cover browse, upload, download, and delete — the connection test probes exactly these:

• s3:ListBucket, s3:GetBucketLocation — on arn:aws:s3:::BUCKET
• s3:GetObject — download files and generate presigned URLs
• s3:PutObject — upload files
• s3:DeleteObject — delete files

(The object-level actions apply to arn:aws:s3:::BUCKET/*.)

Advanced features need more

Bucket-configuration features ask AWS for additional permissions. storafleet operates with whatever subset you grant — anything you haven't allowed simply returns an access-denied response from AWS and that feature is unavailable for the Fleet, nothing breaks:

• s3:GetLifecycleConfiguration / s3:PutLifecycleConfiguration — lifecycle rules
• s3:GetBucketVersioning / s3:PutBucketVersioning — versioning
• s3:GetBucketCors / s3:PutBucketCors — CORS configuration
• s3:GetBucketPolicy, s3:GetBucketPublicAccessBlock — policy / public-access viewers

IAM best practices

Prefer a role over long-lived keys. If you do use access keys, create a dedicated IAM user scoped to the single bucket via the Resource condition — never root credentials, never AmazonS3FullAccess. Rotate keys regularly. The IAM-Role method avoids all of this: nothing long-lived is stored, and the cross-account trust is gated by a per-connection ExternalId.