How to Restrict User Access on AWS - IAM

August 16, 2016 Ron Harnik

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 IAM 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 about 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.

Register for upcoming webinar: "AWS vs Microsoft Azure". Save your Seat!

 

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.

IAM policy enforcement tool

 

Next we need to create our group. Notice that we still don’t attach any policies, we’ll do that later.

Enforce policy on groups of users

 

Finally let’s add our users to the group.

AWS restrict user access

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:


IAM policy management

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:

 

IAM S3 console management

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”:


Amazon S3 user management


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:

EC2 Management console


EC2 management console

 

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.  

 

In Conclusion

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.

 

aws-vs-azure-webinar-1.png

Related posts:
- Security Groups - AWS vs Azure

- Policy Enforcement in Cloud Environments

Previous Article
Enterprise IT vs Cloud: Adapt or Be Disrupted. Surviving Cloud Disruption: Lessons from Lyft, Uber and Airbnb
Enterprise IT vs Cloud: Adapt or Be Disrupted. Surviving Cloud Disruption: Lessons from Lyft, Uber and Airbnb

IT has a very ambivalent relationship to cloud. It’s viewed both as an enabler of growth, because it provid...

Next Article
[AWS vs Azure] Security Groups
[AWS vs Azure] Security Groups

AWS vs Azure: AWS Security Groups and Microsoft Azure Network Security Groups   One of the major challeng...

×

Join thousands of Cloud professionals on the Scalr Newsletter

Thank you!
Error - something went wrong!