Generating correct and appropriate S3 bucket policies and user policies can be a complex task, but these policies are what determine the permissions and access to S3. At a basic level, a policy contains: resources, actions, the effect, the principal, and condition. It’s crucial that you get these components right and are not tempted to copy-and-paste a template that won’t do the job. One of the critical actions to stay away from is allowing access to all objects within a bucket. In this demo, we will walk through an example of how to modify bucket policies. 

When you’re ready to add a bucket policy, follow these steps: 

For a visual guide on how to use and generate S3 bucket policies, watch the full demo. To see Amazon’s list of bucket policy examples, read here. 

Transcription 
So, you can see, here, that we are logged in to our S3 console. We have our bucket. Let’s just review a couple of settings here, quickly. We have our “Default Encryption” settings that are applied to all new objects as they’re written to the bucket. We have server-side encryption enabled using the SSE-KMS method using a customer master key that we have specified. Now, if we come back over here, we take a look at some objects that we have in here. Sure enough, this file is following the default settings. If we come back to our objects list, take a look at this other file - this one is different. It’s using the SSE-S3 method. So, somebody came in here and changed the properties on this file to use an encryption setting that does not agree with our policy. How can we fix that problem? 

Back over here, on our bucket, we can go to the “Permissions” tab and we can use a bucket policy. Now, we could use the policy generator to try to reduce some of the typos that happen when you’re trying to write JSON if that’s not your first language. If you’re trying to write a policy in JSON, you’re going to end up with some “What just happened?” moments. Bucket policies and IAM policies, in general, they’re difficult to get right. If you take one of the examples straight off the internet, and I’ll show you those in a minute, and you just paste those in here, you’re probably going to cut yourself off and you won’t be able to do anything with your bucket anymore. Be very careful when you’re working with bucket policies and be sure to try them out in a sandbox environment first. But let’s take a look at some of these examples and where we can find them. Anywhere where we can set the encryption properties themselves, either on a file or on the bucket, you will notice that there are a couple of “Learn More” links. These pages have some example policies that will help us enforce some of our decisions. Let’s go with this one here since we’re using SSE-KMS. If we just scroll down, there’s an example of a policy that will require us to use SSE-KMS when we actually write that file. You can see that the supply is on the action of PutObject. You might put some other actions in there. Maybe there is a different action for editing the object, or something like that. Then, you can also see that they give us an additional consideration that we can use the server-side-encryption-aws-kms-key-id condition to actually specify our customer master key that must be used when we are applying encryption. That would allow us to enforce the use of the encryption settings using the CMK that we actually want. 

There is also another bucket policy that is helpful to keep in mind, as well, which is to require the use of HTTPS because buckets can be accessed via HTTP. Sure, they default to HTTPS, but they can be used by HTTP, as well. You can see that any access to our bucket will be denied if secure transport is not actually used. So, these are two examples of bucket policies that can be used to enforce some of the security decisions that we’ve made on our buckets. Again, just a word of caution about generating policies, be sure to test them in safe environments so that if you do cut off part of your own access, at least you won’t do that in production.