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.

ACLApplies ToPermissions Added to ACL
privatecan be added to Bucket and objectOwner gets FULL_CONTROL. No one else has access rights (default).
public-readcan be added to Bucket and objectOwner gets FULL_CONTROL. The AllUsers group gets READ access.
public-read-writecan be added to Bucket and objectOwner gets FULL_CONTROL. The AllUsers group gets READ and WRITE access. Granting this on a bucket is generally not recommended.
aws-exec-readcan be added to Bucket and objectOwner gets FULL_CONTROL. Amazon EC2 gets READ access to GET an Amazon Machine Image (AMI) bundle from Amazon S3.
authenticated-readcan be added to Bucket and objectOwner gets FULL_CONTROL. The AuthenticatedUsers group gets READ access.
bucket-owner-readcan be added to ObjectObject owner gets FULL_CONTROL. Bucket owner gets READ access. If you specify this canned ACL when creating a bucket, Amazon S3 ignores it.
bucket-owner-full-controlcan be added to ObjectBoth the object owner and the bucket owner get FULL_CONTROL over the object. If you specify this canned ACL when creating a bucket, Amazon S3 ignores it.
log-delivery-writecan be added to ObjectThe LogDelivery group gets WRITE and READ_ACP permissions on the bucket.

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.

CriteriaIAM PoliciesBucket PoliciesBucket ACLs
AWS RecommendationAWS recommends using IAM policies where you can.You can use bucket policies as its simper way compared to IAM policies.Bucket ACLs is older way of managing access to S3 buckets and generally are not recommended
Environment IAM allows you to centrally manage all permissions to AWS which is easierS3 policies are limited to S3 environment only S3 ACLs are limited to S3 environment only
Use casesIAM Policies can specify permission rules to other AWS Services/resourcesCan only be used with S3Can only be used with S3
ease of use and maintenance IAM policies are easy to maintain when you have a large number of users and you frequently need to make changes to permission levels of users (i.e. user promoted or left organization)S3 policies are easy to create but become difficult to maintain when you lot of users or if you want to make a change to the access level of some user. You might need to update bucket policies for all buckets if some user need more access to S3 bucketsSame as S3 bucket Policies, ACLs are difficult to maintain
Object level controlIAM policies can only be attached to the root level of the bucket and cannot control object-level permissions. Using ACL is that you can control the access level of not only buckets but also of an object using it.If you need to manage object level permissions in S3, then you need to use Bukcet ACLs

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.

Similar Posts