S3 Bucket Policy To Download [BEST] File
Staci Stanowski
With Amazon S3 bucket policies, you can secure access to objects in your buckets, so that only users with the appropriate permissions can access them. You can even prevent authenticated users without the appropriate permissions from accessing your Amazon S3 resources.
This section presents examples of typical use cases for bucket policies. These sample policies use DOC-EXAMPLE-BUCKET as the resource value. To test these policies, replace the user input placeholders with your own information (such as your bucket name).
You can use your policy settings to grant access to public anonymous users which is useful if you are configuring your bucket as a static website. This requires you to disable block public access for your bucket. For more information on how to do this, and the policy required, see Setting permissions for websiteaccess. To learn how to set up more restrictive policies for the same purpose, see How can I grant public read access to some objects in my Amazon S3 bucket?.
Before you complete this step, review Blocking public access to your Amazon S3storage to ensure that you understand and accept the risks involved with allowing public access. When you turn off block public access settings to make your bucket public, anyone on the internet can access your bucket. We recommend that you block all public access to your buckets.
Before you complete this step, review Blocking public access to your Amazon S3storage to ensure you understand and accept the risks involved with allowing public access. When you turn off block public access settings to make your bucket public, anyone on the internet can access your bucket. We recommend that you block all public access to your buckets.
Amazon S3 turns off Block Public Access settings for your bucket. To create a public, static website, you might also have to edit the Block Public Access settings for your accountbefore adding a bucket policy. If account settings for Block Public Access are currently turned on, you see a note under Block public access (bucket settings).
The following example policy requires every object that is written to the bucket to be encrypted with server-side encryption using AWS Key Management Service (AWS KMS) keys (SSE-KMS). If the object isn't encrypted with SSE-KMS, the request will be denied.
The following example policy grants the s3:PutObject and s3:PutObjectAcl permissions to multiple AWS accounts and requires that any requests for these operations must include the public-read canned access control list (ACL). For more information, see Amazon S3 actions and Amazon S3 condition key examples.
The public-read canned ACL allows anyone in the world to view the objects in your bucket. Use caution when granting anonymous access to your Amazon S3 bucket or disabling block public access settings. When you grant anonymous access, anyone in the world can access your bucket. We recommend that you never grant anonymous access to your Amazon S3 bucket unless you specifically need to, such as with static website hosting. If you want to enable block public access settings for static website hosting, see Tutorial: Configuring a static website on Amazon S3.
The following example shows how to allow another AWS account to upload objects to your bucket while ensuring that you have full control of the uploaded objects. This policy grants a specific AWS account (111122223333) the ability to upload objects only if that account includes the bucket-owner-full-control canned ACL on upload. The StringEquals condition in the policy specifies the s3:x-amz-acl condition key to express the canned ACL requirement. For more information, see Amazon S3 condition key examples.
The following permissions policy limits a user to only reading objects that have the environment: production tag key and value. This policy uses the s3:ExistingObjectTag condition key to specify the tag key and value.
The following example policy grants a user permission to perform the s3:PutObjectTagging action, which allows a user to add tags to an existing object. The condition uses the s3:RequestObjectTagKeys condition key to specify the allowed tag keys, such as Owner or CreationDate. For more information, see Creating a condition that tests multiple key values in the IAM User Guide.
The policy ensures that every tag key specified in the request is an authorized tag key. The ForAnyValue qualifier in the condition ensures that at least one of the specified keys must be present in the request.
The following example policy grants a user permission to perform the s3:PutObjectTagging action, which allows a user to add tags to an existing object. The condition requires the user to include a specific tag key (such as Project) with the value set to X.
The following example policy grants a user permission to perform the s3:PutObject action so that they can add objects to a bucket. However, the Condition statement restricts the tag keys and values that are allowed on the uploaded objects. In this example, the user can only add objects that have the specific tag key (Department) with the value set to Finance to the bucket.
Global condition keys are condition context keys with an aws prefix. AWS services can support global condition keys or service-specific keys that include the service prefix. You can use the Condition element of a JSON policy to compare the keys in a request with the key values that you specify in your policy.
In the following example bucket policy, the aws:SourceArn global condition key is used to compare the Amazon Resource Name (ARN) of the resource, making a service-to-service request with the ARN that is specified in the policy. The aws:SourceArn global condition key is used to prevent the Amazon S3 service from being used as a confused deputy during transactions between services. Only the Amazon S3 service is allowed to add objects to the Amazon S3 bucket.
To grant or restrict this type of access, define the aws:PrincipalOrgID condition and set the value to your organization ID in the bucket policy. The organization ID is used to control access to the bucket. When you use the aws:PrincipalOrgID condition, the permissions from the bucket policy are also applied to all new accounts that are added to the organization.
When restricting access to a specific IP address, make sure that you also specify which VPC endpoints, VPC source IP addresses, or external IP addresses can access the S3 bucket. Otherwise, you might lose access to the bucket if your policy denies all users from performing any S3 operations on objects in your bucket without the proper permissions already in place.
The following example bucket policy shows how to mix IPv4 and IPv6 address ranges to cover all of your organization's valid IP addresses. The example policy allows access to the example IP addresses 192.0.2.1 and 2001:DB8:1234:5678::1 and denies access to the addresses 203.0.113.1 and 2001:DB8:1234:5678:ABCD::1.
If you want to prevent potential attackers from manipulating network traffic, you can use HTTPS (TLS) to only allow encrypted connections while restricting HTTP requests from accessing your bucket. To determine whether the request is HTTP or HTTPS, use the aws:SecureTransport global condition key in your S3 bucket policy. The aws:SecureTransport condition key checks whether a request was sent by using HTTP.
If a request returns true, then the request was sent through HTTPS. If the request returns false, then the request was sent through HTTP. You can then allow or deny access to your bucket based on the desired request scheme.
Suppose that you have a website with the domain name www.example.com or example.com with links to photos and videos stored in your bucket named DOC-EXAMPLE-BUCKET. By default, all Amazon S3 resources are private, so only the AWS account that created the resources can access them.
To allow read access to these objects from your website, you can add a bucket policy that allows the s3:GetObject permission with a condition that the GET request must originate from specific webpages. The following policy restricts requests by using the StringLike condition with the aws:Referer condition key.
Suppose that you're trying to grant users access to a specific folder. If the IAM user and the S3 bucket belong to the same AWS account, then you can use an IAM policy to grant the user access to a specific bucket folder. With this approach, you don't need to update your bucket policy to grant access. You can add the IAM policy to an IAM role that multiple users can switch to.
If the IAM identity and the S3 bucket belong to different AWS accounts, then you must grant cross-account access in both the IAM policy and the bucket policy. For more information about granting cross-account access, see Bucket owner granting cross-account bucket permissions.
The following example bucket policy grants JohnDoe full console access to only his folder (home/JohnDoe/). By creating a home folder and granting the appropriate permissions to your users, you can have multiple users share a single bucket. This policy consists of three Allow statements:
AllowRootAndHomeListingOfCompanyBucket: Allows the user (JohnDoe) to list objects at the root level of the DOC-EXAMPLE-BUCKET bucket and in the home folder. This statement also allows the user to search on the prefix home/ by using the console.
When you enable access logs for Application Load Balancer, you must specify the name of the S3 bucket where the load balancer will store the logs. The bucket must have an attached policy that grants Elastic Load Balancing permission to write to the bucket.
Make sure to replace elb-account-id with the AWS account ID for Elastic Load Balancing for your AWS Region. For the list of Elastic Load Balancing Regions, see Attach a policy to your Amazon S3 bucket in the Elastic Load Balancing User Guide.
The following example bucket policy grants a CloudFront origin access identity (OAI) permission to get (read) all objects in your S3 bucket. You can use a CloudFront OAI to allow users to access objects in your bucket through CloudFront but not directly through Amazon S3. For more information, see Restricting access to Amazon S3 content by using an Origin Access Identity in the Amazon CloudFront Developer Guide.
df19127ead