As we’ve seen, Amazon S3 is very simple on paper:
We can store files in buckets.
We can read these files and upload them onto the internet.
When we combine this service with IAM, we can specify who has permission to read buckets, upload files, etc.
But things are never that simple in practice.
Although IAM is a central service for managing access rights on AWS, some services, such as Amazon S3, also give you the option of specifying access rights alongside those defined within IAM policies.
This is where things get interesting.
Managing permissions on Amazon S3 is a bit of a hot topic at the moment. Those who have left buckets containing personal data with open access have had their fingers burned. This happens way more often than we might think.
Define Different Policy Types
Access rights for buckets and files are determined using quite a complicated policy process. I’m going to try to make it easier for you.
There are two types of rules:
IAM policies, which we saw in the last chapter. These define what a user is permitted to do.
Resource-based policies define what we can do with an AWS service resource such as an S3 bucket.
But doesn’t this come down to the same thing?
Yes, but an IAM policy is centered around a user, while the resource-based policy is centered around a resource (bucket or file).
Here’s an example to make it clearer:
IAM policy: “Jennifer has permission to read and update all files in bucket A and can also add PNG files to bucket B.”
Resource policy: “In bucket A, Jennifer has permission to read and update all files, while Patrick only has permission to add files.”
Which policy takes precedence if one policy permits access while another denies access? In AWS, the most restrictive policy always takes precedence. If Jennifer has an IAM policy permitting her to upload a file, but there’s a bucket policy that denies access, Jennifer will get an error message, and vice versa.
In practice, I would recommend that you always use IAM policies to grant permissions to your IAM users and roles. The main purpose of bucket policies is to grant permission to the bucket for the rest of the internet, because, thankfully, you don’t have to define all of your website users within your AWS account!
So, this is how it looks:
IAM policy: “Jennifer from the marketing team can update images in bucket A.”
Bucket policy: “All internet users have read-only access to images in bucket A.”
Next, I’m going to show you where bucket policies start to become interesting.
Get to Grips With Bucket Policies
Here’s a really simple bucket policy. It’s written in JSON format:
{
"Version":"2012-10-17",
"Statement": [
{
"Effect":"Allow",
"Principal": "*",
"Action":["s3:GetObject"],
"Resource":["arn:aws:s3:::examplebucket/*"]
}
]
}Let’s break it down!
Version: the policy version number. Don’t put today’s date, copy the date I’ve used (this essentially means “I’m going to use version 3 of the policy”).
Statement: the policy rules. Here, we only have one. Let’s have a look at what’s inside:
Effect: Allow or Deny
Principal: the user to whom we are granting permission. Here, the asterisk “*” means “Everyone, including the general public on the internet without an AWS account.”
Action: this is the action we want to permit (there might be a number of these). Here,
s3:GetObjectmeans that we are permitted to download an object (a file). The list of actions can be found in the documentation. Yep, there are lots of them! The most important ones include:s3:DeleteObject: allows files to be deleteds3:GetObject: allows files to be read and downloadeds3:PutObject: allows files to be addeds3:ListBucket: allows a list of all filenames in a bucket to be displayeds3:ListAllMyBuckets: allows a list of all buckets to be displayed
Resource: the name of the permitted resource. This one uses a special format. Here,
arn:aws:s3:::examplebucket/*means that we’re granting permission on all files (*) in the bucket calledexamplebucket.
Writing an S3 policy requires a bit of practice. The one we have here is very simple.
I’ve thought about this question in a number of different ways, and I think the best way of understanding it is to use some examples. Let’s have a look at some together.
Discover Policies
Let’s learn how to read some policies.
Example 1
{
"Version": "2012-10-17",
"Id": "ExamplePolicy01",
"Statement": [
{
"Sid": "ExampleStatement01",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::Account-ID:user/Dave"
},
"Action": [
"s3:GetObject",
"s3:GetBucketLocation",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::examplebucket/*",
"arn:aws:s3:::examplebucket"
]
}
]
}This policy grants permission to user Dave (created on AWS IAM) to read an object, find out where a bucket is located, and list the contents of the bucket. If you’re wondering how I know what these actions mean, this is because I’ve read the documentation.
The affected resources are “examplebucket” and all of the files contained inside it.
Example 2
{
"Version":"2012-10-17",
"Id":"ExamplePolicy02",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"AWS":"*"
},
"Action":"s3:GetObject",
"Resource":"arn:aws:s3:::my-brand-new-bucket/public/*"
},
{
"Effect":"Allow",
"Principal":{
"AWS":"arn:aws:iam::Account-ID:user/Dave"
},
"Action":[
"s3:PutObject",
"s3:DeleteObject"
],
"Resource":"arn:aws:s3:::my-brand-new-bucket/*"
}
]
}This policy grants everyone read-only access to objects in the “public” folder of “my-brand-new-bucket.” This means that anyone on the internet will be able to download files from the “public” folder in this bucket, if the user knows its URL. If you’re hosting your website images on Amazon S3, you’ll almost certainly need to grant this permission.
This policy also gives other permissions (you can see that there are two statements). It gives Dave the right to add and delete files anywhere in the bucket.
Summary: everyone can read files in the “public” folder, but only Dave can add or delete them.
Activate Your First Policy
Well, this is great, but how do we implement these policies?
If you want to add a JSON format policy for a bucket, as we’ve just seen, you have to go to the “Permissions”/“Bucket policies” tab for the bucket.
In our example, we’re going to permit all internet users to download files stored in the “public” directory within our kevinopenclassroomsbucket bucket.
By default, AWS will not let you use bucket policies to give public access to a bucket. First, you need to disable this bucket-level protection to tell AWS that we are intentionally exposing some data on the internet. Within the “Block public access” section, click on “Edit.”
Then, uncheck all the boxes and click on “Save.”
Next, navigate further down in the bucket policy.
Click on “Edit” to access the online editor:
The above policy permits read-only access to all files in the bucket to everyone. Essentially, it turns it into a public bucket.
Once you’ve saved the policy, it immediately becomes active (as long as there are no errors). Amazon S3 now warns me that the bucket is public and that I need to be careful not to include any confidential data.
We’ve just been through a short introduction to Amazon S3 access rules. Hopefully, this will help you to get your bearings when you’re starting out. I have to admit, I was completely lost when I first started! Feel free to read the documentation if you want to find out more details!
Let’s Recap!
An IAM policy defines access permissions for a given user.
A resource-based policy defines who can access a given resource.
We recommend that you favor IAM policies to manage access to AWS. Resource-based policies are particularly suited to managing public access to resources, or granting permission to secondary AWS accounts.
In the next and final chapter, we’re going to set aside the operational aspects of AWS to focus on one of the most important services: billing. We’re going to see how to save 40%, 50% or even 60% of your costs by tweaking certain options.
