Mastering the Art of Writing Least privilege AWS IAM Policies

If you are responsible for AWS Security or part of a DevSecOps team, you have to create and manage AWS IAM Policy documents on daily basis, there are a lot of different tools exists to evaluate your AWS IAM policy and recommend the least privilege version, but very few tools or none exist to help you create one so you are mostly left with creating a policy document your self.

Thanks to nice folks at Sales Force they have developed and released Policy Sentry which makes writing the AWS IAM Policy documents with least privilege very easy, even if you are a security focused One of the top AWS Partner like us or you are managing the AWS account for your organization the policy sentry is a must tool in your daily arsenal.

What is Least Privilege Access?

Before we see how policy sentry works lets discuss what is least privilege anyway. Least privilege is the principal specifying that if an application or a user require access to perform a certain action i.e an AWS API Call or an action in AWS Console they should only be able to do that. So for this example blog post we will take an example of reading one s3 object and writing to another S3 object.

To adhere and follow the least privilege principal if I need read access to an object then I should only be able to read that object, I should not be able to write to it or perform any other actions and also I should not be able to read any other object. So specific action scoped to specific resource in an IAM policy statement with an explicit allow or deny.

Similarly if I need write access to an object I should only be able to write to it and not perform any other action including read. This might work and not work in some scenarios and read access might be required to perform write but that means read access is required and it will be granted explicitly.

Installation

Policy sentry is written in Python and release as python package so the installation is very easy and you can run the below command on all operating systems provided you have Python installed.

pip3 install --user policy_sentry

Policy Sentry usage Workflow

The workflow of creating IAM policy documents is very simple and 3 step process in Policy sentry.

1. Create a Policy Sentry template
2. Modify the template and add Resource ARNs
3. Generate the IAM Policy

Create Policy Sentry Template

Policy sentry template is a simple yaml template and you don’t have to learn and understand the syntax, since it is automatically generated by policy sentry command. All you have to do is just modify this template and add the resources on which you want to perform actions such as Read, Write and Permission Management.

To generate the template run the command below.

policy_sentry create-template --output-file policy.yml --template-type crud

The above command will generate the below template.

mode: crud
name: ''
# Specify resource ARNs
read:
- ''
write:
- ''
list:
- ''
tagging:
- ''
permissions-management:
- ''
# Actions that do not support resource constraints
wildcard-only:
  single-actions: # standalone actions
  - ''
  # Service-wide - like 's3' or 'ec2'
  service-read:
  - ''
  service-write:
  - ''
  service-list:
  - ''
  service-tagging:
  - ''
  service-permissions-management:
  - ''
# Skip resource constraint requirements by listing actions here.
skip-resource-constraints:
- ''
# Exclude actions from the output by specifying them here. Accepts wildcards, like kms:Delete*
exclude-actions:
- ''
# If this policy needs to include an AssumeRole action
sts:
  assume-role:
  - ''
  assume-role-with-saml:
  - ''
  assume-role-with-web-identity:
  - ''

Modify the template and add Resource ARNs

Now that we have created the template we need to modify the policy.yml and add our Resource ARNs so we can generate the IAM Policy document. This is the only requirement of Policy sentry that you should know the resource ARN. Lets modify the policy.yml so it looks like following.

mode: crud
name: 'blog-demo'
# Specify resource ARNs
read:
- 'arn:aws:s3:::bucket_name/object_name'
write:
- 'arn:aws:s3:::bucket_2/object_2'

If you notice in the above document I have removed everything and just listed 2 Resource ARNs. The first ARN is an s3 object ARN which is listed under the read section indicating I need read access to that object and the second ARN is another object ARN in another bucket for which I need write access.

Generate the IAM Policy

Now lets generate the IAM Policy from the yml template, run the following command on yml file.

policy_sentry write-policy --input-file policy.yml

The above command will create the IAM policy which will look like below.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3ReadObject",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectAcl",
                "s3:GetObjectAttributes",
                "s3:GetObjectLegalHold",
                "s3:GetObjectRetention",
                "s3:GetObjectTagging",
                "s3:GetObjectTorrent",
                "s3:GetObjectVersion",
                "s3:GetObjectVersionAcl",
                "s3:GetObjectVersionAttributes",
                "s3:GetObjectVersionForReplication",
                "s3:GetObjectVersionTagging",
                "s3:GetObjectVersionTorrent"
            ],
            "Resource": [
                "arn:aws:s3:::bucket_name/object_name"
            ]
        },
        {
            "Sid": "S3WriteObject",
            "Effect": "Allow",
            "Action": [
                "s3:AbortMultipartUpload",
                "s3:DeleteObject",
                "s3:DeleteObjectVersion",
                "s3:InitiateReplication",
                "s3:PutObject",
                "s3:PutObjectLegalHold",
                "s3:PutObjectRetention",
                "s3:ReplicateDelete",
                "s3:ReplicateObject",
                "s3:RestoreObject"
            ],
            "Resource": [
                "arn:aws:s3:::bucket_2/object_2"
            ]
        }
    ]
}

Policy Sentry generated IAM Policy

Now lets talk a little bit about what Policy sentry did for us, it generated the least privilege IAM policy with specific read actions scoped to specific resource and it generated that Policy just from our ARNs. If you notice we didn’t specify the actual IAM actions, it was able to figure out the action details from the Resource ARN which is very cool. This feature is what makes policy sentry a very user friend tool for generating your least privilege IAM policies.

Conclusion

Regardless if you are managing a single AWS account or multiple, you should never create IAM policy with more privileges than what is required. This is the baseline we have set in all of our operations and implementations at SUDO Consultants and this is why Policy sentry is an integral part of our DevSecOps practices. It lets developers create policies with least privilege without forcing them to  learn about IAM policies and AWS Security.