Amazon EC2 Resource-Level Permissions for RunInstances

Derek Lyon sent me a really nice guest post to introduce an important new EC2 feature!

— Jeff;

I am happy to announce that Amazon EC2 now supports resource-level permissions for the RunInstances API. This release enables you to set fine-grained controls over the AMIs, Snapshots, Subnets, and other resources that can be used when creating instances and the types of instances and volumes that users can create when using the RunInstances API.

This release is part of a larger series of releases enabling resource-level permissions for Amazon EC2, so lets start by taking a step back and looking at some of the features that we already support.

EC2 Resource-Level Permission So Far
In July, we announced the availability of Resource-level Permissions for Amazon EC2. Using the initial set of APIs along with resource-level permissions, you could control which users are allowed to do things like start, stop, reboot, and terminate specific instances, or attach, detach or delete specific volumes.

Since then, we have continued to add support for additional APIs, bringing the total up to 19 EC2 APIs that currently support resource-level permissions, prior to today’s release. The additional functionality that we have added allows you to control things like which users can modify or delete specific Security Groups, Route Tables, Network ACLs, Internet Gateways, Customer Gateways, or DHCP Options Sets.

We also provided the ability to set permissions based on the tags associated with resources. This in turn enabled you to construct policies that would, for example, allow a user the ability to modify resources with the tag environment=development on them, but not resources with the tag environment=production on them.

We have also provided a series of debugging tools, which enable you to test policies by making DryRun API calls and to view additional information about authorization errors using a new STS API, DecodeAuthorizationMessage.

Resource-level Permissions for RunInstances
Using EC2 Resource-level Permissions for RunInstances, you now have the ability to control both which resources can be referenced and used by a call to RunInstances, and which resources can be created as part of a call to RunInstances. This enables you to control the use of the following types of items:

• The AMI used to run the instance
• The Subnet and VPC where the instance will be located
• The Availability Zone and Region where the instance and other resources will be created
• Any Snapshots used to create additional volumes
• The types of instances that can be created
• The types and sizes of any EBS volumes created

You can now use resource-level permissions to limit which AMIs a user is permitted to use when running instances. In most cases, you will want to start by tagging the AMIs that you want to whitelist for your users with an appropriate tag, such as whitelist=true. (As part of the whitelisting process, you will also want to limit which users have permission to the tagging APIs, otherwise the user can add or remove this tag.) Next, you can construct an IAM policy for the user that only allows them to use an AMI for running instances if it has your whitelist tag on it. This policy might look like this:

{      "Version": "2012-10-17",      "Statement": [{         "Effect": "Allow",         "Action": "ec2:RunInstances",         "Resource": [            "arn:aws:ec2:region::image/ami-*"              ],         "Condition": {           "StringEquals": {             "ec2:ResourceTag/whitelist": "true"           }         }       },            {         "Effect": "Allow",         "Action": "ec2:RunInstances",         "Resource": [            "arn:aws:ec2:region:account:instance/*",           "arn:aws:ec2:region:account:security-group/sg-1a2b3c4d"         ]       }     ]  }

Or, if you want to grant a user the ability to run instances in a certain subnet, you can do this with a policy that looks like this:

{      "Version": "2012-10-17",      "Statement": [{         "Effect": "Allow",         "Action": "ec2:RunInstances",         "Resource": [            "arn:aws:ec2:region:account:subnet/subnet-1a2b3c4d"         ]       },            {         "Effect": "Allow",         "Action": "ec2:RunInstances",         "Resource": [           "arn:aws:ec2:region:account:instance/*",           "arn:aws:ec2:region:account:image/*",           "arn:aws:ec2:region:account:security-group/sg-1a2b3c4d"         ]       }     ]  }

If you want to set truly fine-grained permissions, you can construct policies that combine these elements. This enables you to set fine-grained policies that do things like allow a user to run only m3.xlarge instances in a certain Subnet (i.e. subnet-1a2b3c4d), using a particular Image (i.e. ami-5a6b7c8d) and a certain Security Group (i.e. sg-11a22b33). The applications for these types of policies are far-reaching and we are excited to see what you do with them.

Because permissions are applied at the API level, any users that the IAM policy is applied to will be restricted by the policy you set, including users who run instances using the AWS Management Console, the AWS CLI, or AWS SDKs.

You can find a complete list of the resource types that you can write policies for in the Permissions section of the EC2 API Reference. You can also find a series of sample policies and use cases in the IAM Policies section of the EC2 User Guide.

— Derek Lyon, Principal Product Manager