Resource-Level Permissions for EC2 and RDS Resources

With AWS being put to use in an ever-widening set of use cases across organizations of all shapes and sizes, the need for additional control over the permissions granted to users and to applications has come through loud and clear.  This need for control becomes especially pronounced at the enterprise level. You don’t want the developers who are building cloud applications to have the right to make any changes to the cloud resources used by production systems, and you don’t want the operators of one production system to have access to the cloud resources used by another.

The Story So Far
With the launch of IAM in the middle of 2010, we gave you the ability to create and apply policies that control which users within your organization were able to access AWS APIs.

Later, we gave you the ability to use policies to control access to individual DynamoDB, Elastic Beanstalk, Glacier, Route 53, SNS, SQS, S3, SimpleDB, and Storage Gateway resources.

Today we are making IAM even more powerful with the introduction of resource-level permissions for Amazon EC2 and Amazon RDS. This feature is available for the RDS MySQL, RDS Oracle, and RDS SQL Server engines.

On the EC2 side, you can now construct and use IAM policies to control access to EC2 instances, EBS volumes, images, and Elastic IP addresses. On the RDS side, you can use similar policies to control access to DB instances, Read replicas, DB Event subscriptions, DB option groups, DB parameter groups, DB security groups, DB snapshots, and subnet groups.

Let’s take a closer look!

Resource-Level Permissions for EC2
You can now use IAM policies to support a number of important EC2 use cases. Here are just a few of things that you can do:

• Allow users to act on a limited set of resources within a larger, multi-user EC2 environment.
• Set different permissions for “development” and “test” resources.
• Control which users can terminate which instances.
• Require additional security measures, such as MFA authentication, when acting on certain resources.

This is a complex and far-reaching feature and we’ll be rolling it out in stages. In the first stage, the following actions on the indicated resources now support resource-level permissions:

• Instances – Reboot, Start, Stop, Terminate.
• EBS Volumes – Attach, Delete, Detach.

EC2 actions not listed above will not be governed by resource-level permissions at this time. We plan to add support for additional APIs throughout the rest of 2013.

We are also launching specific and wild-card ARNs (Amazon Resource Names) for all EC2 resources. You can refer to individual resources using ARNs such as arn:aws:ec2:us-east-1:1234567890:instance/i-i-96d811fe and groups of resources using ARNs of the form arn:aws:ec2:us-east-1:1234567890:instance/*.

EC2 policy statements can include reference to tags on EC2 resources. This gives you the power to use the same tagging model and schema for permissions and for billing reports.

In order to make it easier for you to test and verify the efficacy of your policies, we are extending the EC2 API with a new flag and a couple of new functions.  The new flag is the DryRun flag, available as a new general option for the EC2 APIs. If you specify this flag the API request will perform an authorization determination, but will not actually process the API request (for example, to determine whether a user has permission to terminate an instance without actually terminating the instance). 

In addition, when using API version 2013-06-15 and above, you will now receive encoded authorization messages along with authorization denied errors that can be used in combination with a new STS API, DecodeAuthorizationMessage, to learn more about the IAM policies and evaluation context that led to a particular authorization determination (permissions to the new STS API can be controlled using an IAM policy for the sts:DecodeAuthorizationMessage action).

The final piece of the EC2 side of this new release is an expanded set of condition tags that you can use in your policies. You can reference a number of aspects of each request including ec2:Region, ec2:Owner, and ec2:InstanceType (consult the EC2 documentation for a complete list of condition tags).

Resource Permissions for RDS
You can also use policies to support a set of important RDS use cases. Here’s a sampling:

• Implement DB engine and Instance usage policies to specific group of users. For example, you may limit the usage of the m2.4xl instance type and Provisioned IOPS to users in the Staging users or Production users groups.
• Permit a user to create a DB instance that uses specific DB parameter groups and security groups. For example, you may restrict Web application developers to use DB instances with Web application parameter groups and Web DB Security groups. These groups may contain specific DB options and security group settings you have configured.
• Restrict a user or user group from using a specific parameter group to create a DB instance. For example, you may prevent members of the Test users group from using Production parameter groups while creating test DB instances.
• Allow only specific users to operate DB instances that have a specific tag (e.g. DB instances that are tagged as “production”). For example, you may enable only Production DBAs to have access to DB instances tagged with Production label.

As you might have guessed from my final example, you can now make references to tags on any of the RDS resources (see my other post for information on the newly expanded RDS tagging facility), and you can use the same tags and tagging schema for billing purposes.

As we did for EC2, we have added a set of RDS condition tags for additional flexibility. You can reference values such as rds:DatabaseClass, rds:DatabaseEngine, and rds:Piops in your policies.

For more information, consult the Managing Access to Your Amazon RDS Resources and Database chapter in the RDS documentation.

The AWS Security Blog takes an even more detailed look at this feature and shows you how to use it!

Go For It
These new features are available now and you can start using them today.

— Jeff;