Amazon S3 Access Control - IAM Policies, Bucket Policies and ACLs

Aug 16, 2023

Amazon S3 Access Control - IAM Policies, Bucket Policies and ACLs

In this AWS video tutorial, you’ll learn about the different methods of implementing access control with Amazon Simple Storage Service (Amazon S3) buckets. There are IAM policies, bucket policies, and Access Control Lists (ACLs). As an AWS Certified Solutions Architect, you’ll need to know how they work and which access control methods to use for a specific S3 use case.

After going through the theory you’ll see how to implement each policy type in a series of hands-on examples. You can follow along in your AWS free tier account to practice access control on Amazon S3.

The code needed for the hands-on examples can be found here:
https://youtube-code-download-32132b3…

0:00 Intro
5:21 Access Control Lists
11:01 Bucket Policies
12:30 Bucket Items Policy
14:10 Department Folder Policy
15:28 User Policy
16:41 Bucket Policy

At Digital Cloud Training, our mission is to help you succeed in your #cloud career.

👉 Check out our popular training options for #AmazonWebServices, including

🔸On-Demand Courses https://digitalcloud.training/aws-tra…
🔸Hands-on Challenge Labs https://digitalcloud.training/hands-o…
🔸Cloud Mastery Bootcamps https://digitalcloud.training/cloud-m…

💡 Explore FREE #AWS Training Resources at https://digitalcloud.training/free-aw…

👍 Like, comment, and SUBSCRIBE to our channel for more videos from #digitalcloudtraining. We appreciate your support! / digitalcloudtraining

Content

5.12 -> There are a few ways that we can control access to our buckets and the objects that we store within

11.44 -> our S3 buckets, so in this lesson, I'm going to walk you through IAM policies, bucket policies,

17.76 -> and access control lists. And then in the next couple of lessons, we'll do hands-on to see these

23.36 -> in action as well. So firstly, we have policies created in the Identity and Access Management

30 -> service. Now, these are identity-based policies, which means that they get associated with

36.4 -> principles like users and roles. So with an IAM policy, we're directly applying the permissions

44.32 -> that we want to assign to a principal, to that principal. Or we might be applying them to a group

51.28 -> by attaching a policy to a group and then adding a user into the group. We can specify what actions

57.68 -> are allowed on what AWS resources. So we can say that you're allowed to perform specific actions

64.32 -> on a specific bucket, for example. So with IAM policies, these are attached to users

70 -> or groups or roles. And remember, with a group, you attach the policy to the group and then you

75.6 -> add the user to the group, and they will get the permissions assigned to that permissions policy.

80.72 -> IAM policies are written in JSON using the AWS access policy language, and the principal element

87.6 -> is not required in the policy. So when you see one of these JSON snippets of code,

93.04 -> if it doesn't have a principal element in it, then

96.4 -> that means that it could be an IAM policy that's used for S3 rather than a bucket policy.

102.16 -> So next, we have S3 bucket policies, and these are resource-based policies. So with a bucket policy,

108.64 -> you're attaching it directly to an S3 bucket. They can only be attached to Amazon S3 buckets,

115.84 -> and they also use the same access policy language. So it's still JSON,

120.4 -> looks very much like the policies created at the identity level, but it's on a resource instead.

127.2 -> We might have an S3 bucket, we apply our bucket policy to it, and a bucket policy might look

133.12 -> something like this. So note that there is a principal element here, which specifies the

139.36 -> specific user we want to assign these permissions to. There's also a resource, and it specifies the

146.4 -> bucket name. And of course, there's an action, which in this case is "s3: *". The effect is

151.68 -> allowing, the action is "s3: *", so a wildcard for S3 actions. So in this case, Paul will be

159.36 -> able to put an object into that S3 bucket because he's allowed through the resource-based policy.

166.24 -> Lastly, we have access control lists. These are really a legacy access control mechanism

172.8 -> that predates Identity and Access Management. AWS generally recommends that you try and use bucket

178.56 -> policies or IAM policies rather than using ACLs. They can be attached to a bucket or directly to

186.32 -> an object. So a bucket policy is always at the bucket level, whereas an ACL can be specified

192.96 -> at the object level as well. There are limited options for grantees and permissions.

198.16 -> We'll see this in the hands-on. It's not as powerful as using the access policy language.

204.32 -> So when might you use these different access control mechanisms? You might use IAM policies

210.08 -> for the following use cases: where you need to control access to AWS services other than S3,

216.64 -> because you can then specify whatever permissions you want to whatever AWS service, as well as

223.44 -> the S3 bucket. You have numerous S3 buckets, each with different permission requirements.

228.88 -> So that means you're centrally controlling access to lots of different buckets using a single IAM

234.96 -> policy, which is centralizing the management and hopefully simplifying it. You might just

240.16 -> prefer to keep access control policies in the IAM environment rather than using resource-based

245.36 -> policies, which can be a bit harder to track. So you might want to use bucket policies if

249.84 -> you want a simple way to grant cross-account access to S3 without using IAM roles. You can

256.72 -> do that quite easily in a bucket policy. Your IAM policies might be reaching the size limits.

262.08 -> There is a limit on the size of an IAM policy, so that might force you to use a bucket policy,

268.32 -> or you might just prefer to keep your access control policies in the S3 environment. And that

273.68 -> could be down to separation of control within your organization. It's important to understand the

279.28 -> authorization process, so let's work through the logic. The decision will always start at a deny,

285.76 -> and then it evaluates the policies and looks for explicit denies. If there is an explicit deny,

292.88 -> then that's the end. The final decision is deny. Next, if there isn't an explicit deny, we look

299.28 -> for any allows. If there is an allow, then the decision is to allow. That's an explicit allow.

306.64 -> If there isn't one, then the decision is deny. So that's basically the process for how authorization

312.56 -> works. Now in the next lesson, we're going to look at access control lists in a hands-on,

317.44 -> and then we're going to look at IAM policies and bucket policies. In this lesson, we're

322.24 -> going to have a look at access control lists on Amazon S3. In the S3 console,

327.52 -> I'm going to click on my bucket here, DCT Cloud Storage, and under permissions, we can see the

334.56 -> access control list just a bit further down here. Now, as you can see, there's a warning telling

339.68 -> me I can't actually enable public access because it's disabled at the bucket level.

345.36 -> So the first thing I want to do because what I want to do as an exercise in this lesson is

350.24 -> actually enable public access for my objects. So what I'll first need to do is unblock public

357.04 -> access. Now let's just check the behavior at this stage. Let's go to one of our objects,

363.36 -> copy the URL, and then put it into a browser window. And I get an access denied message,

369.44 -> and that's completely expected. So what I need to do is go back up to my bucket level here,

376 -> choose permissions, click on edit under block public access, and deselect this option.

382.88 -> Click on save, and then confirm. So now it's been confirmed.

387.2 -> If we just scroll down to access control list and let's edit the access control list. Now note that

395.36 -> there are a few different options here for the grantees. So a grantee is either the bucket owner,

402.4 -> everyone, authenticated users, so anyone with an AWS account who has authenticated,

409.04 -> or the S3 log delivery group for storing log files. So those are the only options. And then

414.96 -> we have list and read and so on. So there are a few permissions and a few options for grantee.

420.96 -> It's not hugely powerful like a bucket policy or an identity and access management policy.

427.04 -> Now, this is the ACL at the bucket level. Remember, there's also an ACL at the object level.

433.2 -> So I actually don't need to enable list access to my bucket to enable direct access to my object.

440.16 -> So in fact, I'm going to leave this as it is. Let's click on objects, choose one of my objects,

448.16 -> go to permissions, and then edit here. Here, I can enable read access for everyone. That's

455.44 -> public access for my object. I have to click on a checkbox here to understand what the impact

461.52 -> is of this change, and then click on save. Now let's go back and refresh our screen. This time,

468.88 -> I can see the object, so it's now public. Another way you can achieve the same outcome

475.36 -> is you can select an object, go to actions, and make it public. Click on "Make Public,"

482.88 -> and that's done. Now, if I go into this object, what you'll be able to see

488.64 -> under the permissions tab is that we've given read access, exactly the same thing. So just

494.88 -> as with the other file, we should now be able to access this one, and we can see the image.

500.48 -> So that's how you work with ACLs. Now, let's just go back up to our bucket level and

505.92 -> permissions. Another thing worth noting is the cross-account access. So let's click on "Edit,"

514.96 -> and at the bottom here, you can see access for other AWS accounts. This is a common use case

520.8 -> for using an ACL. In this case, you can add the grantee, and you can enter the canonical ID, which

527.04 -> is essentially a form of the account ID, and then give some basic permissions to anyone within that

534.56 -> account. So that's all I want to show you for this lesson. One thing I am going to do is just go back

540.56 -> up and put the block public access back on again. And now the configuration of our bucket is back to

547.04 -> the way it was at the beginning of the lesson. Hi, guys! In this lesson, we're going to cover using

552.08 -> bucket policies and user policies. User policies are the IAM policies that we create and attach to

558.48 -> our users. Now, there are a couple of things that you're going to need to set up. Firstly, you need

563.36 -> a second user account. I've got one called "pool," but you can call this user whatever you want. Now,

569.2 -> that user will need management console access. At this stage, the user should not be in any groups,

576.32 -> so effectively, that user does not have any permissions. Now,

579.92 -> I've logged in as that user into a private window, and that means I'm logged into my main account

587.12 -> with my own admin privileges in one window, and then in a private window or incognito window,

593.12 -> I'm logged in as "pool." So, "pool" at this stage should not have any access. If you go into Amazon

599.6 -> S3, what we should see is this: "You don't have any permissions to list buckets." So the user

605.92 -> has no privileges to S3 at this point in time. Now, we also want to add a couple of folders

612.24 -> and some files to our bucket. So I'm going to use the same bucket, "DCT Cloud Storage." What we're

618.08 -> going to do is create a folder. This one's going to be called "Department." Just create the folder.

623.76 -> Then we're going to create another one. This one's going to be called "Confidential." And then going

628.32 -> to go into the "Confidential" folder, upload, add files, and I'm going to choose this file,

635.84 -> "Confidential Report." So you can just create your own documents and call them whatever you want.

640.48 -> So mine's called "Confidential Reports," a Word document. I'm going to upload that file,

645.28 -> then close out of here, back up a level, choose the "Department" folder, upload, add files,

653.52 -> and this time I'm going to choose this company goals PDF. So that's the structure set up. Now,

659.04 -> let's have a look at the policies that we're going to use. In your course download in the

663.2 -> code directory, Amazon S3, you're going to have this file, "User Policies and Bucket Policies,"

668.88 -> and we've got some numbered items in here. So the first one is we're going to attach a user

674.16 -> policy to our user, which allows that user to list buckets. So the privilege is s3:ListAllMyBuckets,

682.32 -> and the resource is "*" so that means any AWS bucket that we have. It's a star, it's a wildcard.

690.16 -> So what I'm going to simply do is copy this code here from the opening and the closing

696.16 -> curly braces. Back in IAM, I'm going to choose my second user account. Mine's called "pool,"

702 -> and I'm going to add an inline policy. Click on the JSON tab, remove the existing code,

708.08 -> and paste my new code in. Let's click on "Review." I'm just going to call this "pool

714.24 -> inline," and then let's create the policy. Now, don't worry about this summary here. We're going

719.2 -> to see what privileges this does assign to "pool." So we've attached that policy. Let's

724.32 -> go over to the other browser window where "pool" is logged in. So now I'm back logged in as "pool."

730 -> Let's refresh my screen here, and I can now list the buckets. So you can see there's an access

737.12 -> warning here of insufficient permissions. All I have here is the permission to list the bucket.

742.96 -> So if I click on "DCT Cloud Storage," I can't see any objects within the bucket. I can only

748.64 -> list that the bucket level. So let's go to the next policy. It says, "C. Root level bucket items

755.28 -> user policy." So what does this one do? So here we have the "ListAllMyBuckets" and

760.56 -> "GetBucketLocation" privileges. We then have the s3:ListBucket, which is an "Allow" for a specific

770.48 -> bucket name. In this case, it was "DCT Policy Test." Now I need to change that for my bucket.

776.08 -> So make sure you change this value here. Now the condition is that the string equals a prefix and

782.64 -> a delimiter of a slash. So what this should do is allow us to see the items within the bucket.

789.12 -> So let's copy all of this code to our clipboards. And then back logged in as my main user account,

796.64 -> I'm going to edit this policy, click on JSON, delete all the code, and paste this in.

803.28 -> Now, remember, I do need to change my bucket name here. So back on S3 with my bucket selected,

810.16 -> I'm going to go to properties and ARN. I can copy that to my clipboard, come back,

816.96 -> and I can paste that in. So I can replace the entire ARN here. And let's save this policy.

823.52 -> Now, let's go back over to "pool" back logged in as "pool." I'm trying to look at the

828 -> objects within my bucket here. Let's click on the refresh, and you see that now I can actually see

835.76 -> these objects. Can I download an object? Let's have a look. And I get an "Access is denied."

840.56 -> What about going in and looking at items in "confidential"? Well, now I don't have

845.28 -> permissions, so we're getting quite granular here in the permissions we're assigning to this user.

850.24 -> Now, let's move on to the next policy. This is to view the "department" folder contents.

856.4 -> Now, what you may notice is we've got a lot of the permissions here that we had

860.32 -> in the previous policy, and then we have some additional permissions at the bottom here.

864.64 -> So here we have the s3:ListBucket, we again need to replace our ARN. So let me paste my new ARN in.

873.28 -> It also has to be back up here, so make sure you do that. Make sure you change your ARN.

880.08 -> And what this last policy statement here is going to do is allow us access to the "department"

886.48 -> folder star. So anything within the "department" folder. So let's go and copy all of this code.

892.4 -> I'm again going to edit the policy, click on JSON, delete everything out, paste this in.

899.2 -> Just as a reminder, make sure you've got the correct ARN for your bucket. And then let's

905.76 -> review policy and save. So back logged in as "pool," let's refresh. But I'm trying to look

911.36 -> in the "confidential" folder here, and we didn't give those permissions, so I'm not getting access.

917.04 -> Let's come back up to the bucket level, try "department," and we can see. So we've now enabled

923.28 -> this user to see right down to the objects within the "department" folder. But as you saw before,

929.04 -> we haven't given any permissions for uploading or deleting objects yet. So the next policy here

935.2 -> is still a user policy, and the first three of these sections are the same as before.

942.72 -> And then the very last one at the bottom here allows the s3:GetObject and s3:PutObject

949.68 -> actions. Now I'm going to go to my previous policy, copy this ARN. Let's come down.

956.4 -> There's going to be multiple places we need to put this. As you can see, it's highlighted the

960.48 -> three places. So let's change in all three of these locations. And be careful with the last

966.88 -> one. You want to keep the slash "department star." So that's it. I should be able to

973.28 -> copy this code. Let's again edit our policy, go to JSON, delete this out, put our new code in,

981.52 -> review, and save. So back in the "department" folder, let's now see if we can download our

988.48 -> object. And that works. I can see my file downloading. And I should also be able to

993.28 -> upload objects because I gave the permission to put object. So let's just choose any file

999.28 -> and try and upload. And that's also a success. The last policy is a bucket policy, and we need

1006.64 -> to use this in combination with policy two above. Now let's just copy our ARN again. So remember,

1013.04 -> the ARN up to the name of the bucket. I'm going to copy that. I'm going to paste it over the ARN in

1020.08 -> my resource section of my bucket policy. Then we need to use user policy two. So we need to go back

1027.28 -> up to policy two. And I remember I didn't actually update this one in my file. So I'm going to update

1034.08 -> my ARN here as well. Copy this code. We're going to edit "Paul's" policy again, paste that in.

1041.92 -> And this will give the user the list level at the top of the bucket again. So let's just save those

1048.48 -> changes. If we come back to "Paul," who's trying to look in the "department" folder and refresh,

1053.36 -> we should find that soon we get denied access. And there we go. That took a couple of refreshes. It

1059.12 -> can sometimes take a bit of time. So what about at the bucket level here? And yes,

1064.48 -> we can see the objects at this level. Now, what if we go into the "confidential" folder?

1070.48 -> Well, here we certainly don't have permissions because we can only see at the level above.

1075.44 -> So coming back to the code now, we need to use the bucket policy. And the bucket policy is going

1080.96 -> to allow the specific user. So you're going to need to go and get the ARN of your user,

1088.88 -> which you can find inside the user account here. Just copy the ARN to your clipboard and then

1094.8 -> paste that in. So this principle will be allowed the action s3:star. So nes3 action

1101.52 -> on the resource dct cloud storage, our bucket name, and then the prefix is under a condition. So

1109.44 -> the condition is limiting this access. So nes free action but only on this prefix,

1115.52 -> which is the confidential folder, and then slash star, which means the objects within

1120.72 -> the folder. The slash star indicates that the privileges are assigned to the objects

1126.08 -> within the folder as well. So let's copy all of this, and now we're going to go and add a bucket

1133.04 -> policy. So back in S3, I'm in my bucket here, and under permissions, let's scroll down a little way

1140.24 -> and click on edit next to bucket policy. And we're going to paste our policy in. And just

1146.56 -> in case you haven't updated your ARN, you can get it easily here as well. You can copy it

1151.12 -> and then paste it in and make sure you've got the correct ARN. So let's save these changes,

1156.88 -> come back to Paul, let's click on refresh, and now we have our access again. And we now

1162.72 -> have full permissions to the confidential folder only. So that's how we work with user policies as

1169.12 -> well as bucket policies. And as you can see, we can actually use them together as well.

Source: https://www.youtube.com/watch?v=xFzJw6wJ8eY