My Favorite AWS IAM Policies

Recently, I have been working on a set of advanced AWS courses that will provide in-depth guidance on how to approach application design to deployment from development to production. It has been an exciting experience putting together all these years of learnings in the form of courses. While I continue to work on these, I had put together a set of my favorite AWS IAM policies that can help in specific scenarios. Feel free to use these as base and evolve.

In order to better understand these policies we have 2 teams in play here.

1. DevOps: They are responsible for overall infrastructure, build-to-release and lifecycle management of critical resources, such as, VPCs, etc.
2. Dev: The development team that uses the resources provisioned by DevOps and builds application components on top. They also work closely with DevOps to keep improving the automation of stack deployment iteratively.

Scenario: Restrict ability to manage specific EC2 Instances

Let’s take an example wherein the developers should only be able to start/stop/reboot instances that belong to the Dev team only.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "EC2BasicAccess",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeInstanceStatus",
                "ec2:DescribeTags"
            ],
            "Resource": "*"
        },
        {
            "Sid": "EC2InstanceAccess",
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances",
                "ec2:RebootInstances"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Team": "Dev"
                }
            }
        }
    ]
}

Here’s a quick explanation.

• We use the non-resource specific actions like ec2:DescribeInstances so that developers can navigate to the instances.
• The DevOps team uses a Team tag to mark the ownership of resources (in this case, the EC2 instance has been marked for Dev team.) Typically, this will be done via the DevOps pipelines.
• The policy uses condition to restrict start/stop/reboot actions to EC2 instances with (Team == Dev). Even if the developers can see other EC2 instances, they will not be able to act on these as these will have a different value for the Team tag.

Scenario: Restrict ability to manage objects under a specific S3 Bucket

Let’s take an example wherein the developers should only be able to manage objects under the app-bucket.

Note: As we know, S3 bucket names are globally unique. So, the name shown in this policy is for illustration purpose. You can replace the name with your specific bucket name(s).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "S3BasicAccess",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "*"
        },
        {
            "Sid": "S3AccessOnAppBucket",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::app-bucket"
        },
        {
            "Sid": "S3AccessOnAppBucketObjects",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::app-bucket/*"
        }
    ]
}

Here’s a quick explanation.

• We use actions like s3:ListAllMyBuckets so that developers can navigate to the bucket.
• The statement S3AccessOnAppBucket provides access to the app-bucket content.
• The last statement S3AccessOnAppBucketObjects permits specific actions on the app-bucket objects.

 

Always remember to be as restrictive with IAM policies as possible. Some times exceptions are ok. But those should really be exceptions. I will continue to add as I build more interesting IAM custom policies.

So, stay tuned!
– Nitin