In the previous blog, we have learned about IAM policies in AWS. We can use IAM policies to manage access for different users for the S3 bucket. Obviously, life is not that simple. With S3 we have Bucket policies and Bucket Access Control Lists ( hereafter referred to as ACLs) which also can be used to manage access to S3 buckets. Let us understand the difference between IAM policies VS S3 Policies and S3 ACLs and when should you use what.
IAM Policies
IAM policies are used to specify which actions are allowed or denied on AWS services/resources for a particular user. for example, user Tom can read files from the “Production” bucket but can write files in the “Dev” bucket whereas user Jerry can have admin access to S3.
We can attach IAM policies to users, groups, or roles. These users or roles can perform AWS operations depending on permission granted to them by AWS policy.
Below is a sample policy that allows read access to s3 bucket “test-sample-bucket”. Any user or group or role which has the below policy attached will be able to read data from this bucket.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": "arn:aws:s3:::test-sample-bucket"
}
]
}
S3 Bucket Policies
With the S3 bucket policy, you can specify which actions are allowed or denied on that bucket for some users. The user in the context of S3 bucket policies is called the principal. The principle can be IAM user or AWS root account. That means you can grant access to another AWS account than in which your AWS S3 bucket is created.
S3 bucket policies can be attached to only S3 buckets. You can use them with any other AWS user or service. Below is a sample S3 bucket policy that grants root user of AWS account with ID 112233445566 and the user named Tom full access to the S3 bucket.
{
"Id": "Policy1586088133829",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1586088060284",
"Action": "s3:*",
"Effect": "Allow",
"Resource": "arn:aws:s3:::test-sample-bucket",
"Principal": {
"AWS": [
"arn:aws:iam::112233445566:root",
"arn:aws:iam::112233445566:user/Tom"
]
}
}
]
}
Note “Principal” statement in S3 bucket policy. The principal has a list of users who have access to this bucket. In the case of IAM policies “Principal” is not necessary as this is derived from the user or group or role to which IAM policy is assigned.
In the case of IAM policies, mentioning “Principal” is not necessary as this is derived from the user or group or role to which IAM policy is assigned.
AWS Facts
If you want to try and play around to create S3 bucket policies then AWS has provided a policy generator. You can try out creating policies for different scenarios.
S3 Bucket ACL
S3 ACLs is the old way of managing access to buckets. AWS recommends the use of IAM or Bucket policies. But there are still use cases where ACLs give flexibility over policies. That is one of the reasons ACLs are still not deprecated or going to be deprecated any time soon.
The biggest advantage of using ACL is that you can control the access level of not only buckets but also of an object using it. Whereas IAM or Bucket Policies can only be attached to buckets but not to objects in the bucket, Bucket ACLs can be assigned to buckets as well as objects in it.
This means you have a lot of flexibility and control over your S3 resources. You can make some object public in a private bucket or vice versa without any issue.
ACLs can have one of the following types of values.
IAM Policies VS S3 Policies VS S3 Bucket ACLs – what should I Use?
Now that we have understood the basics of IAM Policy, Bucket Policy, and Bucket ACLs, We can decide in which scenario we should use which type of access control. Below is a table that should help you decide what you should use in your case.
Conclusion
I hope you have learned the difference between IAM policies, S3 policies, and S3 ACLs. It is your decision to use one of them depending on your use case. If you have any questions, let me know. See you in the next blog. Cheers.
2 Comments
Comments are closed.