How do I restrict bucket access with resource-based policies?

1. Introduction

This article gives examples of resource-based policies that are applied to individual buckets. These policies are used to restrict which users can access a particular bucket and what S3 protocol actions they may perform. Resource-based policies can also be implemented to ensure only S3 protocol access over encrypted HTTPS is allowed to access the bucket.  

2. Identity versus Resource-based Policies

For cases where users are defined in the Wasabi account, you can use either resource-based or identity-based policies. Resource-based policies are applied to resources (buckets), whereas identity-based policies are assigned to groups or users. See How to Separate Access at a Bucket Level for more details on identity-based policies.

3. Example Resource-based Policies

3.1 Limit User Bucket Access 

The following is an example of a resource-based policy. This policy limits who can access a particular bucket and has an implicit deny-all entry that prevents non-root users from accessing the bucket without the users being explicitly specified in the policy. It is applied to the resource (the bucket), not to users/groups. 

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "LimitBucketAccess",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::AccountNumber:user/User1",
"arn:aws:iam::AccountNumber:user/User2",
"arn:aws:iam::AccountNumber:user/UserN"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::BucketName",
"arn:aws:s3:::BucketName/*"
]
}
]
}

Note:  Leave the Version number alone.  It does not represent the current date; rather it specifies the policy language version.

The AccountNumber may be obtained by looking at the Users list on the Wasabi console. This number is the same for all users under the same account.  After replacing AccountNumber, User1, User2, up to UserN, and BucketName, copy and paste the policy into the bucket Policies in the Wasabi console (click on Buckets, the name of the bucket, Settings (gear wheel), Policies).

Instead of "Action": "s3:*", which allows all S3 actions, you may use a more restrictive list of S3 actions such as the following that only allows users to list objects in the bucket and get objects, not delete objects, upload objects, etc.:

"Action": ["s3:GetObject","s3:ListBucket"],

3.2 Limit User Bucket Access + Force HTTPS 

Here is the same resource-based policy that also forces the use of HTTPS, mandating the use of encryption while the data is in transit: 

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "LimitBucketAccess",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::AccountNumber:user/User1",
"arn:aws:iam::AccountNumber:user/User2",
"arn:aws:iam::AccountNumber:user/UserN"
]
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::BucketName",
"arn:aws:s3:::BucketName/*"
]
},
{
"Sid": "EnforceHTTPS",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::BucketName",
"arn:aws:s3:::BucketName/*"
],
"Condition": {
"Bool": {
"aws:SecureTransport": "false"
}
}
}
]
}

3.3 Add-On Identity-Based Policy for S3 Client Compatibility

In addition to the resource-based policies above, use the following identity-based policy for compatibility with more S3 client applications. Apply it preferably to a user group, or to individual users.  

Caution: Some S3 clients require being able to list all buckets and will fail without this policy. Given that, only use this policy if you want users to be able to see the names of other users' buckets.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "arn:aws:s3:::*"
}
]
}

3.4 Policy to Force HTTPS Without User Restrictions 

You may also use a bucket policy to only force the use of HTTPS when accessing the bucket data. Here is an example of such a policy that doesn’t restrict user access as described above.

{ 
"Version": "2012-10-17", 
"Statement": [ 
{ 
"Sid": "AllowBucketAccess", 
"Effect": "Allow", 
"Principal": { 
"AWS": [ 
"arn:aws:iam::AccountNumber:*" 
] 
}, 
"Action": "s3:*", 
"Resource": [ 
"arn:aws:s3:::BucketName", 
"arn:aws:s3:::BucketName/*" 
] 
}, 
{ 
"Sid": "EnforceHTTPS", 
"Effect": "Deny", 
"Principal": { 
"AWS": "*" 
}, 
"Action": "s3:*", 
"Resource": [ 
"arn:aws:s3:::BucketName", 
"arn:aws:s3:::BucketName/*" 
], 
"Condition": { 
"Bool": { 
"aws:SecureTransport": "false" 
} 
} 
} 
] 
} 

After replacing BucketName and AccountNumber, copy and paste the policy into the bucket policies in the Wasabi console (click on Buckets, the name of the bucket, Settings (gear wheel), Policies). 

3.5 Policy to Force HTTPS Without Any Non-Root User Access

You can use the following policy to force encrypted HTTPS access.  Other identity-based policies in conjunction with this bucket policy may be used to allow user access to the bucket. 

{ 
"Version": "2012-10-17", 
"Statement": [ 
{ 
"Sid": "EnforceHTTPS", 
"Effect": "Deny", 
"Principal": { 
"AWS": "*" 
}, 
"Action": "s3:*", 
"Resource": [ 
"arn:aws:s3:::BucketName", 
"arn:aws:s3:::BucketName/*" 
], 
"Condition": { 
"Bool": { 
"aws:SecureTransport": "false" 
} 
} 
} 
] 
} 

3.6 Screenshot Examples from Policy Testing 

The following are example screenshots from Cyberduck while testing the policies. The identity-based policy in Section 3.3 was implemented in all tests to allow for users to list buckets, but it is not required.

This screenshot is for the policy in Section 3.1 that was defined to allow access to a bucket named “logging-bucket” for a “logging” user. It shows the logging user being able to see the contents of the logging-bucket.

The following screenshot is for the policy in Section 3.5 that was defined to deny non-HTTPS access. It shows the root user receiving an Access Denied error when trying to access the bucket over unencrypted HTTP.