IAM Root: AWS IAM Simulator Tutorial

If you needed yet another reason to be paranoid about your personal information being exposed, the recent Capital One breach should be sufficient nightmare fuel for you. This is even more supporting evidence that your SSN isn’t secret anymore. Sensitive information of over 100 million people was exposed during this attack.  I won’t go over some of the technical details of what happened during the breach. There are a couple of articles that already do that on this article and this blog article. We even have an in-depth webinar covering it. From what we know so far, the two big problems that led to the breach were a misconfigured firewall and a EC2 instance that had full access too much access to S3. The real question on people’s minds is “How do I prevent this from happening?” 

In a previous post, I’ve argued that rigorously locking down IAM roles and policies is an important way to secure AWS resources. In this post, I’ll be doing a deeper dive into the AWS Policy Simulator. We’ll be using the online console for this tutorial. If you’re interested in scripting around this, then you could use it in the AWS CLI tool.

Overview

In the console, the IAM Sim has two modes,  one for Existing Policies and the other for New Policy. The image above shows the menu in Existing Policies mode. The only difference between them is that panel 1 is replaced with a button that opens a simple text editor to write the json for a given policy. For this tutorial, I’m going to assume that you’re comfortable with json. If not you can always use the AWS Policy Generator to write it for you. The censored box at the top represents the user (or assumed role) that you are currently using the simulator as. The top menu also has a help menu icon (📘) that just redirects you to the documentation for the simulator. 

1. User, Groups, and Roles Panel (or Policy Sandbox) – In Existing Policies mode you can use the panel to test running commands as any existing user, role, a member of an existing group.  In New Policy mode this is replaced with a simple json editor. 
2. Service Panel – This is where you select the services that you want to test for. You can test a handful of actions by checking for specific actions on a service, or you can do “Select All” to test all actions on a given service
3. Global Settings – We won’t be touching this one, but if you’re already an IAM wizard and you have some policies that require MFA, or policy variables that use the username, then you can provide those details here.
4. Action Settings and Results – This menu allows for you to test actions on resources. The default is “*” for a given resource, but you can click the arrow icon (⏵) for any action and specify an arn of any resource. For example, if you want to test if your policy prevents a user for accessing an object in S3, you would use an arn like arn:aws:s3:::bucket_name/key_name. For more examples of arns of other services are in the documentation.

Note: If you’re a tab junky like myself, you need to know that New Policy mode does NOT save the json for the new policy that you’re editing. If you (are forced to) refresh the page, you will lose the policy that you were working on and have to start over.

Example Simulations

For a quick example, I’m going to run a scenario based on an Insecure EC2 Role. Let’s pretend that we’re a flustered dev who doesn’t understand IAM permissions very well. This person is tasked with accessing S3 from within an EC2 instance to manage the file. Rather then take a few minutes to construct a role to access a specific bucket or a folder within a bucket, the dev finds a sketchy tutorial online and creates an EC2 role with the FullS3Policy attached like so.  

If we go into the simulator we can select this role under the dropdown menu of the User, Groups, and Roles Panel in Existing policies mode and run simulations based on it. Lets see what EC2 instances with this role can do in S3.

Well, not only does this EC2 instance have the ability to modify files stored in S3, it can also modify the policies on the buckets to control access, upload whatever file(s) to any bucket and download, list & delete ANY  file and bucket in S3. There is absolutely no reason to give anything this much access in S3. If an attacker gains access to this EC2 instance, they can cause all sorts of havoc on your cloud storage.

We can also run a simulation on a policy that is much more sane, like the one below. This policy only allows limited read write permissions on a specific bucket called my_bucket. This would be the minimum policy you would need to be able to download and upload files on one s3 bucket.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my_bucket",
        "arn:aws:s3:::my_bucket/*"
      ]
    }
  ]
}

We can also check specific buckets and files. Under the action menu click the arrow (⏵) of any action with the resource type bucket and include the arn for that bucket. A valid arn from the example above is arn:aws:s3:::my_bucket. For actions with the resource type object, use an arn like this arn:aws:s3:::my_bucket/* which means any object on the bucket. 

There we have it. We’ve now tested a specific IAM role that fits the use case for the EC2 instance. EC2 instances with this role will only be able to download and upload files to a specific s3 bucket and will not be able to do those actions on other buckets, or even list them. 

Note: You may notice the informational icon (ℹ️) next to the status of the simulation. This is because the simulator runs simulations purely based on the IAM policy by default. In order to run simulations while taking the resource policy into account. You need to attach the “s3:GetBucketPolicy” action to the policy that allows the simulator to access a bucket’s policy. 

  The simulator doesn’t only work with EC2 and S3. You can use it to configure IAM policies for any AWS service, including IAM itself. For example, if you don’t want certain users to have access to the simulator, you can always use a simple deny policy and attach it to the proper Roles, Groups or Users you want to block access for. Deny statements take precedence over any allow, so if a user or service is given full IAM access they still will be denied on the action(s) specified.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenySimulatorAccess",
      "Action": [
        "iam:SimulateCustomPolicy",
        "iam:SimulatePrincipalPolicy"
      ],
      "Effect": "Deny",
      "Resource": "*"
    }
  ]
}

Closing Thoughts

With the AWS Policy Simulator it is so much easier to fine tune access control for aws. You can quickly sketch out IAM policies or test existing ones without spending hours fighting with Access Denied errors. It also gives anyone who has access to it the opportunity to quickly understand the security implications of certain policies and create precise. 

We write a lot about posts on AWS feel free to check those out if you’re interested. We also do cloud security assessments. If you are interested or have general questions about cloud security, please contact us and include “Cloud Security” in the subject or body of the form.