Understanding inbuilt AWS S3 security controls and methods — Part 2

Originally published on Medium

This article is the second part of a series of articles on understanding inbuilt AWS S3 security controls and methods. You can access part 1 of the series by visiting here.

In this article, we will shift our focus toward the access control policies that can be defined to control access to your AWS S3 buckets. Those can be mainly divided into two main components as follows,

1 — Identity-based policies

2 — Resource-based policies

Let’s go through each one of them and understand how can we leverage those to control access to our S3 buckets.

1 — Identity-based policies

Identity-based policies are the ones that can be directly attached to a user, a group that the user belongs or a role via the IAM service in AWS. These can be either inline or managed. Given below is a sample example of an IAM policy that allows the assigned identity to Put an Object, Get an Object, List an Object, Delete an Object and Get Bucket location access to the awsexamplebucket and its internal objects. The second statement also allows the identity the ability to list all the bucket's permission.

One thing to note here that is identity-based policies cannot grant anonymous access to the bucket as it's always attached to a user.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AssignUserActions",
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:DeleteObject",
        "s3:GetBucketLocation"
      ],
      "Resource": [
        "arn:aws:s3:::awsexamplebucket1/",
        "arn:aws:s3:::awsexamplebucket1"
      ]
    },
    {
      "Sid": "ExampleStatement2",
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*"
    }
  ]
}

Likewise, there are a lot of actions, resource types, and condition keys to use within IAM policies, which offers you full flexibility in defining the permissions to your S3 buckets with identity policies.

To view all available actions, resource types, and condition keys on S3, refer https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazons3.html

2 — Resource-based policies

As the name implies these policies provide access controls from the resource’s side, which are associated with either S3 objects or buckets. Due to this its required to also define what principal or in simple terms who will have the allowed/ denied access to that specific resource-based policy. From an S3 perspective, resource-based policies can be divided into two main types,

2.1 — Bucket Policies

Bucket policies can be used to grant IAM users and other AWS accounts permissions to your bucket and objects in it. It's defined at the individual bucket level.

Bucket policies can be added to a bucket when you click the bucket and within the Permissions tab in the AWS management console. You can also do the same programmatically as everything else if you were wondering. Bucket policies are defined in JSON. Given below is a sample bucket policy, which allows anonymous access (As the Principal is set to *) to Get objects from awsexamplebucket1. Going beyond this you can even set conditions into your bucket policies. You can refer to the link I attached above to view the available options.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GrantAnonymousReadPermissions",
      "Effect": "Allow",
      "Principal": "",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": [
        "arn:aws:s3:::awsexamplebucket1/"
      ]
    }
  ]
}

2.2 — ACLs

ACLs, allow you to control access to buckets and additionally to specific objects within bucket groupings and AWS accounts. ACL is a list containing grants identifying grantees and permissions associated with them. It is defined as Amazon S3–specific XML schema. Here is a sample view of the ACL settings by default to the bucket. You can access this by clicking on the S3 bucket and going to the permissions tab within the AWS management console.

By editing the above configurations, you can also add access to another AWS account as a grantee and set up a bucket and object-specific access. The object ACL only has two permissions as List, and Write from the object ACL, unlike Write, Read permission for the Bucket ACL. Read object allows the grantee to read the object data and its metadata. Read object permissions allows the grantee to read the object ACL. Write object permissions allow the grantee to write the ACL for the object.

As AWS now recommends, for most of the general use cases it's better to go off just with ACLs disabled option as we have discussed in Part 1. But it again may depend on your use case.

In a situation where all three of the controls are used to control access to an S3 bucket, S3 will view all these policies together and any permission conflict between policies will be handled in accordance with the principle of least privilege.

Few points to keep in mind related to occasions when permission conflicts are derived,

**- AWS S3 follows the principle of least privilege and by default, it defines that access is denied to an object even though an explicit denial is not mentioned within any policy.

• Allow should exist within a policy that principal is associated or defined within a bucket policy or ALC. Access will be granted only if Allow is defined within a policy and Deny if not defined.

• If a single Deny is defined as associated with the principal to a specific object, access will be Denied despite having an Allow in another policy. In simple terms, Deny always takes precedence over Allow when permissions are assessed.**

We have discussed multiple ways of controlling access to your S3 buckets using policies within this article. I hope by now, it's clear that you can use all the available policy types to control access to your AWS S3 bucket together.

Before finalizing, I would also like to highlight some key considerations that you have to keep in mind when planning to use different access control policies.

When to consider using Identity Based policies,

• To centrally manage access control methods all within one service.

• If you manage a large number of buckets and multiple permissions should be added to all those buckets, Identity-based policies will be ideal and easy to manage.

When to consider using Resource Based policies,

• If you need to granularly control the security of your S3 buckets only within the S3 service itself and within the bucket level, bucket policies can be considered ideal.

• If your policy file is a bit large, there are size constraints on IAM policies compared to bucket policies (IAM policies can be a maximum of two kilobytes in size for users, five kilobytes for groups, and 10 kilobytes for roles. However, bucket policies can reach a size of 20 kilobytes)

Based on your use case, security, compliance, and regulatory requirements you can leverage all the above access control policies together to achieve the maximum security you can obtain using S3 access control policies.

Let’s deep dive into other additional security controls and methods provided by AWS S3 in the upcoming articles on this article series.

References

1 — https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-overview.html

2 — https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-s3-evaluates-access-control.html

3 — https://cloudacademy.com/course/increasing-your-security-posture-when-using-amazon-s3-1235

Comments

[Serge Eby]

Great read!
Minor typo: "Due to this its required to also define what principle ...." should read "Due to this its required to also define what principal..."

[Ravindu Nirmal Fernando]

@sdeby Thanks for pointing out. Its fixed now.