How to restrict access on AWS Iam
IAM (Identity and Access Management) is the AWS tool for creating and enforcing access policies. In this article, we’ll be focusing on how to use IAM to enforce permission policies on users, but Identity and Access Management also allows administrators to enforce access profiles on EC2 instances, determining which other AWS services they can interact with.
The access management aspect of IAM works by defining a policy and attaching it to a user. The best practice is to not attach policies directly to users but to place users in groups and attach the policy to the group.
The AWS documentation does a fantastic job laying down the basics of how everything works, so we’re not going to go through that here. Instead, let’s consider the following scenario.
An administrator wants to restrict an app team to only be able to:
- Provision t2 instances or m3.medium instances, in the us-east-1 region only
- Access the “AppTeam1” S3 bucket
Let’s see how the administrator should go about using IAM to enforce this policy.
Step 1 – Create The “AppTeam1” IAM Group
If we want a group we first need users! Go to the Identity & Access Management Service and create some new users.
Next we need to create our group. Notice that we still don’t attach any policies, we’ll do that later.
Finally let’s add our users to the group.
Great! Now it’s time to create our policy.
Step 2 – Create a policy and attach it to the “AppTeam1” Group
IAM policies are defined through JSON files. There are 3 ways to create policies in IAM:
- Copy an existing IAM policy and edit it
- Create a policy though the policy generator
- Write your own JSON policy
The first two options are usually preferred since that way there’s less of a chance to make a mistake. Mistakes are very easy to make in IAM since there are a lot of little things to consider, like “NotActions” being different than “Deny” for example. You can easily create a policy that will get validated by the IAM policy editor, but will in practice will not do the thing you wanted it to do.
Having said that, the policy generator tends to be a bit simplistic, as we’ll see in the example below. For this scenario our best bet is to carefully build our own policy, and then validate it and test it.
It’s considered best practice to create small, “tight” policies rather than large ones that cover multiple resources. So we’re going to create two policies, one to limit the EC2 instance types the app team can use and the region they can use them in and another to limit their S3 access.
Our first policy will grant the App Team access to a single bucket on the S3 service. First let’s try the policy generator.
From the IAM dashboard, click on Policies and then Create Policy. Select the Policy Generator. Here’s what I entered:
AWS service points to S3, all actions allowed, with the resource in question being the “appteam1” bucket (which I already created). When created the policy looks like this:
Pretty straightforward! Allow access to S3, specifically to the “appteam1” bucket. However, if we attach this policy to our group and attempt to login with one of our users, we’ll get the following message:
While the generated policy allows all actions within S3, it does not grant users access to the S3 console. In practice, the policy we need looks like this:
Now when we try to access S3 as a member of the App Team we get “Access Denied” messages on all buckets but “appteam1”:
Awesome, we’re halfway there, on to the next policy.
For our next trick we’re going to limit the EC2 instance types the App Team can use, and make sure they can only provision in the us-east-1 region.
Let’s begin with granting our users EC2 access, but for the N.Virginia region only:
Simple enough, with this policy attached to our group the App Team users can only operate EC2 in the designated region:
Now let’s add the instance type restriction. If the administrator wanted to deny only a few instance types, it would make sense to simply point them specifically under a “Deny” statement. Since we want to go the other way around and only allow a few instance types, denying everything that isn’t the instance types we want makes for a cleaner policy :
On Reactive Policies
We’ve written in the past about reactive and preventative policies, and how you should have both for effective cloud management. An important note on IAM is that it’s purely reactive. If you deny a user from provisioning a certain type of instance, they’ll only get the error message after they’ve gone through the instance creation wizard.
They way IAM works is by waiting for the users to perform actions and then checking their permissions to see if the action can be executed. This approach work in many cases, but can also lead to waste. For example, if a user selects the “Create New Security Group” option during instance creation, but the provisioning fails due to lack of permissions, the security group will still be created. This can be a frustrating user experience.
IAM is an extremely powerful policy enforcement tool. This was just one example, but you can pretty much enforce any policy you can think of, including making sure administrators can only enforce certain types of policy.
The reason I chose to work through an example instead of just listing out all the things you need to know about IAM, is because that’s pretty much the only way to learn how to use it. IAM is powerful but it’s also very sensitive, it’s easy to make mistakes and you need to learn how it works. AWS provides a policy simulator that allows you to test your policies before putting them in production. Logging some hours on the simulator might make a difference once your policies get complicated.
Stay tuned to the blog for the next post in the series, which will explain how to work through the same scenario using Azure access policies.