Bucket Access Policies
Control user actions on specific resources
Bucket access policies are JSON objects that define allowed or denied actions on a single bucket and its contents. Use a bucket access policy when you need precise, S3-specific access control for one bucket. Only the bucket owner can attach or update this policy.
CoreWeave AI Object Storage enforces access in two layers:
- Organization access policies apply to all principals and resources in your organization. You configure them in the Cloud Console or via the AI Object Storage API (for example, with
curl
). These policies are evaluated first. - Bucket access policies apply only to one bucket and its objects. You set them using the S3 API with tools such as
aws s3api
ors3cmd
. These policies are evaluated after organization access policies.
For the complete evaluation order, see the Policy Overview.
How to set a bucket access policy
To set a bucket access policy, you can use the S3 API with standard S3 tools like aws s3api
or s3cmd
. The policy is a JSON object that defines the access rules for the bucket and its objects.
For example, to set a bucket access policy using aws s3api
, you can use the following command:
$aws s3api put-bucket-policy --bucket my-bucket --policy file://my-bucket-policy.json
This command applies the policy defined in my-bucket-policy.json
to the bucket named my-bucket
. The policy must be a valid JSON object that adheres to the structure and rules defined in this guide.
Key considerations
Bucket access policies have some specific aspects and considerations that are important to understand:
Policy Aspect | Details |
---|---|
Policy Scope | Bucket access policies can only grant S3 API permissions. Actions under the cwobject: API (e.g., managing access keys or audit logging) must be allowed via an organization access policy using "Resource": ["*"] . |
Lifecycle Configuration | Bucket access policies uniquely govern bucket lifecycle configuration, including: • Expiration actions (delete by date, age, or expired-marker) • Noncurrent version expiration • Aborting incomplete multipart uploads |
Access Policies vs. Lifecycle Policies | Bucket access policies are not the same as lifecycle policies. Lifecycle policies are used to manage object lifecycles, while bucket access policies control access to the bucket and its objects. • Access policies are set with s3:PutBucketPolicy .• Lifecycle policies are set with s3:PutBucketLifecycleConfiguration . |
Global Operations | Certain actions are global and only evaluate org policies: • s3:ListAllMyBuckets must specify "Resources": ["*"] .• s3:PutBucketPolicy is treated as global and only checks organization access policies to avoid lock-out. |
Principal Specification | Cloud Console groups can't be used in bucket access policies. Instead, specify principals by UID (from Cloud Console) or via SAML users/groups. |
Explicit S3 API Access | Cloud Console admin status does not grant S3 API access—you must explicitly allow it via organization or bucket access policies. |
Structure of bucket access policies
Bucket access policies use JSON objects with two top-level fields: Version
, Statement
. The Statement
field is an array of objects, each defining the access rules for a specific bucket or object. Each statement can include the following:
- Sid: An optional identifier for the policy statement.
- Effect: Indicates whether the policy allows or denies access.
- Principal: The user, role, or group to which the policy applies.
- Action: The specific actions that the policy allows or denies.
- Resource: The resources to which the policy applies, specified in ARN format.
- Condition: An optional element that specifies additional constraints for when the policy applies.
Version
Version
is required. It defines the version of the policy language used. Use 2012-10-17
for all policies. Some old policies use 2008-10-17
. Any other value is invalid.
{"Version": "2012-10-17","Statement": [{"Sid": "UniquePolicyName","Effect": "Allow","Principal": { ... },"Action": [ ... ],"Resource": [ ... ],"Condition": { ... }}]}
Statement
Statement
is required. It's the main policy element that defines the access rules for buckets and objects. It can contain a single policy or an array. Each policy is enclosed in curly braces, with arrays of policies enclosed in square brackets.
{"Version": "2012-10-17","Statement": [{"Sid": "UniquePolicyName","Effect": "Allow","Principal": { ... },"Action": [ ... ],"Resource": [ ... ],"Condition": { ... }},{ ... },{ ... }]}
Sid
Sid
(Statement ID) is optional. It's a short, human-readable identifier for the policy statement, which is useful for tracking and managing policies. Each Statement
in an array of statements can have an assigned Sid
. Each Sid
must be unique within the JSON policy, and may only consist of only ASCII uppercase, lowercase, or numbers.
{"Version": "2012-10-17","Statement": [{"Sid": "UniquePolicyName","Effect": "Allow","Principal": { ... },"Action": [ ... ],"Resource": [ ... ],"Condition": { ... }}]}
Effect
Effect
is required. It specifies whether the statement allows or denies the action. The valid options are Allow
or Deny
, and these are case-sensitive. By default, access to resources is denied. To allow access to a resource, you must set the Effect
element to Allow
. To override an allow that is otherwise in force, set the Effect
element to Deny
.
{"Version": "2012-10-17","Statement": [{"Sid": "UniquePolicyName","Effect": "Allow","Principal": { ... },"Action": [ ... ],"Resource": [ ... ],"Condition": { ... }}]}
Principal / NotPrincipal
Either Principal
or NotPrincipal
are required; they cannot be used together.
The key can either be "AWS"
or "CW"
, and the value is an ARN (Amazon Resource Name).
- Use
Principal
to specify the user, role, or group allowed for this policy. - Use
NotPrincipal
to deny access to all, except the principal specified. Use with"Effect":"Allow"
is not supported.
Important: Troubleshooting the side-effects of NotPrincipal
can be difficult. We strongly recommend using options such as Condition
instead.
{"Version": "2012-10-17","Statement": [{"Sid": "UniquePolicyName","Effect": "Allow","Principal": {"CW": "arn:aws:iam:::user/<ORG>:<USER>"},"Action": [ ... ],"Resource": [ ... ],"Condition": { ... }}]}
Action / NotAction
Either Action
or NotAction
are required; they cannot be used together.
- Use
Action
to describe the specific actions that are allowed or denied. - Use
NotAction
to match everything except the specified actions.
Wildcards such as s3:*
are allowed to match multiple actions. Be careful when combining NotAction
and "Effect": "Allow"
in the same policy because it could grant users more permissions than intended. See the list of API calls and required actions to determine what actions must be allowed for each API call.
{"Version": "2012-10-17","Statement": [{"Sid": "UniquePolicyName","Effect": "Allow","Principal": { ... },"Action": ["s3:ListBucket","s3:GetObject"],"Resource": [ ... ],"Condition": { ... }}]}
Resource / NotResource
Either Resource
or NotResource
are required; they cannot be used together.
- Use
Resource
to apply the policy to the listed resources. - Use
NotResource
to apply the policy to all resources except the ones listed.
Use ARN format to specify resources. Wildcards *
and ?
are allowed within each colon-separated ARN segment. Wildcards do not extend past colon boundaries.
Important: Do not use NotResource
in tandem with "Effect": "Allow"
and "Action": "*"
because this allows all actions on all resources except those listed.
{"Version": "2012-10-17","Statement": [{"Sid": "UniquePolicyName","Effect": "Allow","Principal": { ... },"Action": [ ... ],"Resource": ["arn:aws:s3:::my-bucket/my-key-name","arn:aws:s3:::???-bucket/*/test"],"Condition": { ... }}]}
Condition
Condition
is optional. A Condition
consists of an operator, and a key with a value. The condition is evaluated to grant or deny access based on the request context.
Condition operators
The supported condition operators are:
- IpAddress: The specified IP address or range, such as
203.0.113.0/24
- NotIpAddress: All IP addresses except the specified address
- StringEquals: Exact, case-sensitive match
- StringNotEquals: Match all except specified string, case-sensitive
- StringLike: Case-sensitive match allowing wildcards
- StringNotLike: Negated case-sensitive match allowing wildcards
- StringEqualsIgnoreCase: Exact match, ignores case
- StringNotEqualsIgnoreCase: Negated exact match, ignores case
- Null: Check for absent condition key
Condition keys
The supported condition keys are:
cw:PrincipalArn
: The principal, formatted asarn:partition:service:region:account-id:[resource-type/]resource-id
cw:ResourceArn
: The resource ARN of the request.cw:ResourceOrgCloudID
: The cloud-id from the owner of a resource.cw:PrincipalOrgCloudID
: The cloud-id from the principal.cw:SourceIP
: The source IP address of the request.cw:Bucket
: The bucket name of the request.
{"Version": "2012-10-17","Statement": [{"Sid": "UniquePolicyName","Effect": "Allow","Principal": { ... },"Action": [ ... ],"Resource": [ ... ],"Condition": {"IpAddress": {Operator"cw:SourceIP": "203.0.113.0/24"Key with value}}}]}
Example use cases
Below are examples bucket access policies for various use cases. You can use these examples as templates to create your own bucket access policies tailored to your specific needs.
Full access to a specific bucket for one user
This policy grants full access to a specific bucket for one user. It has two statements:
- The first statement allows the specified user to perform all S3 actions on the bucket and its contents.
- The second statement denies all other users from accessing the bucket and its contents.
{"Version": "2012-10-17","Statement": [{"Sid": "AllowOnlyOneUser","Effect": "Allow","Principal": {"CW": "arn:aws:iam:::user/<ORG>:<USER>"},"Action": "s3:*","Resource": ["arn:aws:s3:::mybucket","arn:aws:s3:::mybucket/*"]},{"Sid": "DenyAllOthers","Effect": "Deny","NotPrincipal": "*","Action": "s3:*","Resource": ["arn:aws:s3:::mybucket","arn:aws:s3:::mybucket/*"]}]}
Read-only for a specific bucket for all users
This policy grants read-only access to a specific bucket for all users. It has two statements:
- The first statement allows all users to list the bucket and get its location.
- The second statement allows all users to get objects from the bucket.
{"Version": "2012-10-17","Statement": [{"Sid": "AllowListBucket","Effect": "Allow","Principal": "*","Action": ["s3:ListBucket","s3:GetBucketLocation"],"Resource": "arn:aws:s3:::mybucket"},{"Sid": "AllowGetObjects","Effect": "Allow","Principal": "*","Action": "s3:GetObject","Resource": "arn:aws:s3:::mybucket/*"}]}
Read-only for a specific bucket for a specific user
This policy grants read-only access to a specific bucket for a specific user. It has two statements:
- The first statement allows the specified user to list the bucket and get its location.
- The second statement allows the specified user to get objects from the bucket.
{"Version": "2012-10-17","Statement": [{"Sid": "UserReadBucket","Effect": "Allow","Principal": {"CW": "arn:aws:iam:::user/<ORG>:<USER>"},"Action": ["s3:ListBucket","s3:GetBucketLocation"],"Resource": "arn:aws:s3:::mybucket"},{"Sid": "UserGetObjects","Effect": "Allow","Principal": {"CW": "arn:aws:iam:::user/<ORG>:<USER>"},"Action": "s3:GetObject","Resource": "arn:aws:s3:::mybucket/*"}]}
All buckets read-only for all users
This policy grants read-only access to all buckets for all users. It has three statements:
- The first statement allows all users to list all buckets.
- The second statement allows all users to list and describe all buckets.
- The third statement allows all users to get objects from all buckets.
{"Version": "2012-10-17","Statement": [{"Sid": "ListAllBuckets","Effect": "Allow","Principal": "*","Action": "s3:ListAllMyBuckets","Resource": "arn:aws:s3:::*"},{"Sid": "ListAndDescribeBuckets","Effect": "Allow","Principal": "*","Action": ["s3:ListBucket","s3:GetBucketLocation"],"Resource": "arn:aws:s3:::*"},{"Sid": "GetAllObjects","Effect": "Allow","Principal": "*","Action": "s3:GetObject","Resource": "arn:aws:s3:::*/*"}]}
Mapping required policies and actions
Each API call requires permission to perform one or more related actions, and those action names do not always match the API calls. Some API calls perform multiple actions that require permission to separate actions. For example, copying an object requires permission to perform both s3:PutObject
and s3:GetObject
actions.
Use the permission mapping below when planning bucket access policies. See Object Storage API Features for a complementary list of API calls mapped to their associated actions.
Required action permission | API call |
---|---|
s3:AbortMultipartUpload | s3:AbortMultiPartUpLoad |
s3:CreateBucket | s3:CreateBucket |
s3:DeleteBucket | s3:DeleteBucket |
s3:DeleteObject | s3:DeleteObject s3:DeleteObjects |
s3:DeleteObjectTagging | s3:DeleteObjectTagging |
s3:DeleteObjectVersion | s3:DeleteObjects |
s3:DeleteLifecycleConfiguration | s3:DeleteBucketLifeCycle |
s3:DeleteBucketPolicy | s3:DeleteBucketPolicy |
s3:DeleteBucketTagging | s3:DeleteBucketTagging |
s3:GetLifecycleConfiguration | s3:GetBucketLifecycleConfiguration |
s3:GetBucketLocation | s3:GetBucketLocation |
s3:GetBucketPolicy | s3:GetBucketPolicy |
s3:GetBucketTagging | s3:GetBucketTagging |
s3:GetBucketVersioning | s3:GetBucketVersioning |
s3:GetObject | s3:CopyObject s3:GetObject s3:GetObjectAcl s3:GetObjectAttributes s3:HeadObject s3:UploadPartCopy |
s3:GetObjectTagging | s3:GetObjectTagging |
s3:ListAllMyBuckets | s3:ListBuckets |
s3:ListBucket | s3:GetBucketACL s3:HeadBucket s3:ListObjectsV2 s3:ListObjectVersions |
s3:ListMultipartUploadParts | s3:ListParts |
s3:ListBucketMultipartUploads | s3:ListMultiPartUploads |
s3:PutLifecycleConfiguration | s3:PutBucketLifecycleConfiguration |
s3:PutBucketPolicy | s3:PutBucketPolicy If no policy exists, access to create a new policy is granted if the user's Org ID matches the bucket's organization. |
s3:PutBucketTagging | s3:PutBucketTagging |
s3:PutBucketVersioning | s3:PutBucketVersioning |
s3:PutObject | s3:CompleteMultiPartUpLoad s3:CopyObject s3:CreateMultiPartUpLoad s3:PutObject s3:UploadPart s3:UploadPartCopy |
s3:PutObjectTagging | s3:PutObjectTagging |
Bucket lifecycle policy
Bucket lifecycle policies automate object management in CoreWeave AI Object Storage. Each policy consists of rules that apply actions to objects or their versions.
Lifecycle rule actions:
- Transition: Move objects to a different storage class. (Not supported currently.)
- Expiration: Delete objects after a specified period. CoreWeave AI Object Storage handles deletion automatically. If multiple rules apply, the earliest expiration wins.
- Noncurrent Version Expiration: For versioned buckets, remove older object versions after a defined count or time.
- Abort Incomplete Multipart Uploads: Delete multipart upload parts left incomplete after a set number of days.
The example below shows how to configure each action. Refer to the following section for field definitions.
{"Rules": [{"Expiration": {"Date": timestamp,"Days": integer,"ExpiredObjectDeleteMarker": true|false},"ID": "string","Prefix": "string","Filter": {"Prefix": "string","Tag": {"Key": "string","Value": "string"},"ObjectSizeGreaterThan": long,"ObjectSizeLessThan": long,"And": {"Prefix": "string","Tags": [{"Key": "string","Value": "string"}...],"ObjectSizeGreaterThan": long,"ObjectSizeLessThan": long}},"Status": "Enabled"|"Disabled","NoncurrentVersionExpiration": {"NoncurrentDays": integer,"NewerNoncurrentVersions": integer},"AbortIncompleteMultipartUpload": {"DaysAfterInitiation": integer}}...]}
Rule | Definition |
---|---|
Expiration | This type of rule specifies that an object will be deleted when it reaches either a listed Date,a number of days old, or an expired Delete marker is present. The date must be in ISO 8601 format and the time in UTC 0000. |
ExpiredObjectDeleteMarker | Indicates whether CoreWeave will remove a delete marker with no noncurrent versions. If set to true , the delete marker will be expired; if set to false the policy takes no action. This cannot be specified with Days or Date. |
ID | Identifier for the rule itself. Can be up to 255 characters |
Filter | Specifies objects for which a rule should apply. Must contain only one of a Prefix , Tag , or And value. An empty Filter indiscriminately applies to all objects in a bucket |
Prefix | A prefix for an object to match on. For instance foo/ will match both foo/bar and foo/baz . Only one prefix per rule can match |
Tag | A dict specifying a specific tag (key) and its value. Multiple tags can be used at once with And |
And | Allows you to match on multiple tags and up to one prefix. |
ObjectSize | You can specify a range of sizes in bytes using ObjectSizeGreaterThan and ObjectSizeLessThan |
Status | Status shows whether this rule should be enabled or not. If the rule is disabled it will not be applied. |
NoncurrentVersionExpiration | Specifies how long and how many non-current versions of a versioned (or versioning suspended) object to keep. |
NoncurrentDays | How many days after an object becomes noncurrent before deletion |
NewerNoncurrentVersions | Deletion will only occur after the specified number of non-current versions is reached. The process starts with the oldest version |
AbortIncompleteMultipartUpload | Specify a number of days after starting a multi-part upload using DaysAfterInitiation to delete all parts if uploading is aborted. |