Resource-Level Permissions for EC2–Controlling Management Access on Specific Instances

Note: As of March 28, 2017, Amazon EC2 supports tagging on creation, enforced tag usage, AWS Identity and Access Management (IAM) resource-level permissions, and enforced volume encryption. See New – Tag EC2 Instances & EBS Volumes on Creation on the AWS Blog for more information.

We are happy to announce that we launched resource-level permissions for EC2 today. The official announcement can be found here. To help you take advantage of these new features for securing your EC2 environment, we will be publishing a series of posts covering common scenarios and best practices. This week’s guest blogger, Derek Lyon, Product Manager on the EC2 team, will explain how we address one of our most commonly-requested use cases: managing access to specific EC2 instances.

Customers have been able to use IAM policies to control which of their users or groups could start, stop, reboot, and terminate instances across all EC2 instances under an account. With this release of EC2-based resource permissions, customers can now strictly control which IAM users or groups can start, stop, reboot, and terminate specific EC2 instances. This ability to assign control of an individual instance to a specific user or group helps organizations implement important security principles like separation of duties (preventing critical functions from being in the hands of one user) and least privilege ( providing each user access only to the minimum resources they need to do their job). For example, you probably don’t want to give everyone in your organization permission to terminate business-critical production instances, so now you can assign that privilege to only a few trusted administrators. Below is a four-step process that will show you how to use our new resource-level permissions feature along with IAM policies to help protect specific instances.

Step 1: Categorize your instances

The most flexible way to categorize your instances is by tagging them. For smaller environments, simple descriptive tags like “critical=true” may be sufficient. For larger environments, you may want to organize your instances into more complex schemas using multiple tags. Some examples of tags that could be used to organize your instances include: “stack=prod”, “service_tier=1”, “app=corporate_website”, “layer=db”, “department=engineering”, “cost_center=153”. For information on how to apply tags to your instances, see the Tagging Your Amazon EC2 Resources documentation.

Step 2: Define how authorized users can (or can’t) manage specific instances

Because IAM policies are based on least privilege, users will not be able to manage your critical instances unless you give them permission to do so. To create a policy that defines permissions to start, stop, reboot, and terminate specific instances (e.g., the ones with a specific tag that you gave them, like “critical”), construct the policy as follows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",	  
        "ec2:RebootInstances",
        "ec2:TerminateInstances"
      ],
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/critical":"true"
        }
      },
      "Resource": [
        "arn:aws:ec2:your_region:your_account_ID:instance/*"
      ],
      "Effect": "Allow"
    }
  ]
}

To add more security controls around users who manage specific instances, you may want to require the use of multi-factor authentication within a time period (e.g. the last 15 minutes). You can also force users to come from a trusted source IP range when making the start, stop, reboot, or terminate requests. You can construct this policy as follows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",	  
        "ec2:RebootInstances",
	"ec2:TerminateInstances"
      ],
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/critical":"true"
        },
        "NumericLessThan": {
          "aws:MultiFactorAuthAge": "900"
        },
        "IpAddress": {
          "aws:SourceIp": "xxx.xxx.xxx.xxx/24"
        }
      },
      "Resource": [
        "arn:aws:ec2:your_region:your_account_ID:instance/*"
      ],
      "Effect": "Allow"
    }
  ]
}

Note that the policies above would only grant the ability to manage instances that have the tag you specified, in this case “critical”. If the user(s) to whom this policy is applied should have the ability to manage other, non-critical instances as well, then additional policy statements are required to define those other instances.

In some contexts, you may optionally choose to explicitly deny a group of users the ability to manage specific instances. Explicit denial policies are not generally required, since IAM is deny-all by default, but the use of an explicit deny policy can provide an additional layer of protection, since the presence of a deny statement will cause the user to be denied the ability to perform an action even if another policy statement would have allowed it. To explicitly deny a user the ability to manage a critical instance, construct the policy as follows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",	  
        "ec2:RebootInstances",
	"ec2:TerminateInstances"
      ],
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/critical":"true"
        }
      },
      "Resource": [
        "arn:aws:ec2:your_region:your_account_ID:instance/*"

      ],
      "Effect": "Deny"
    }
  ]
}

Step 3: Lock down your tags

If you choose to use tags as a basis for setting permissions on instances, you will want to restrict which users have permissions to apply and remove tags. For EC2, you will want to restrict which users have permissions to use the ec2:CreateTags and ec2:DeleteTags actions, so that only these users will be able to change your instance inventory. We will be enabling tag-specific permissions for ec2:CreateTag and ec2:DeleteTags in the future, which will enable you to set permissions on a per-tag basis.

*August 2016 Update* One way to work around this is to use a combination of an Amazon CloudWatch Events rule and AWS Lambda to tag newly created instances. See How to Automatically Tag Amazon EC2 Resources in Response to API Events for more information.

Step 4: Attach your policies to IAM users

As with other IAM policies, you can attach any of the policies above to any IAM principal, including individual IAM users, groups, and roles. The policies will only apply to the principals they are attached to, so you will want to perform periodic audits to ensure that the policies have been deployed appropriately.

Additional Information

Below are some additional resources that you may find helpful as you create policies to manage instances:

“IAM Policies”, a new section in the EC2 User Guide that provides an introduction to IAM policies for EC2 along with several use cases.
“Permissions”, a new section in the EC2 API Guide that provides on overview on creating IAM policies for EC2 from an API perspective.

Watch the AWS Security Blog in the coming weeks for more examples of how to use EC2 resource-level permissions.

– Jim

Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.