Secure Amazon EC2 Environment with AWS IAM & Resource-Based Permissions (CPN205) | AWS re:Invent 2013

© 2013 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc.

Derek Lyon, Principal Product Manager (AWS)November 13, 2013

Securing Your Amazon EC2 Environment with IAM Roles and Resource-Based Permissions

Friday, November 15, 13

https://portal.reinvent.awsevents.com/connect/sessionDetail.ww?SESSION_ID=1118




Agenda• Orientation• Roles for EC2 Instances• EC2 Resource-level Permissions• Coming Soon: Permissions for RunInstances• Iterating and Debugging• Additional Resources



Orientation


Orientation


Orientation• We’ll focus on authorization and credential issues in

order to address “Who can do what?” type problems



order to address “Who can do what?” type problems• We’ll often speak at the API level, though the

approaches apply in the console and tools as well




approaches apply in the console and tools as well• We’ll assume you that have created Users and

Instances before, and likely a lot more than just that




approaches apply in the console and tools as well• We’ll assume you that have created Users and

Instances before, and likely a lot more than just that• We’ll take an Amazon EC2-centric view



Roles for EC2 Instances


What is a Role?


What is a Role?• Roles describe a set of capabilities


What is a Role?• Roles describe a set of capabilities• Roles can be assumed by Users


What is a Role?• Roles describe a set of capabilities• Roles can be assumed by Users• Roles can also be passed to Instances


What is a Role?• Roles describe a set of capabilities• Roles can be assumed by Users• Roles can also be passed to Instances • A User can only assume one Role at a time


What is a Role?• Roles describe a set of capabilities• Roles can be assumed by Users• Roles can also be passed to Instances • A User can only assume one Role at a time• Role permissions are established by policies


What is a Role?• Roles describe a set of capabilities• Roles can be assumed by Users• Roles can also be passed to Instances • A User can only assume one Role at a time• Role permissions are established by policies• Role credentials have pre-set expiration times


What is a Role?• Roles describe a set of capabilities• Roles can be assumed by Users• Roles can also be passed to Instances • A User can only assume one Role at a time• Role permissions are established by policies• Role credentials have pre-set expiration times• They are a great way to manage permissions


A Simple Example


A Simple Example• I define a “web-admin” Role


A Simple Example• I define a “web-admin” Role• I give the “web-admin” Role permission to run and

terminate web servers (and possibly more…)



terminate web servers (and possibly more…)• I grant several Users permission to assume the

“web-admin” Role



terminate web servers (and possibly more…)• I grant several Users permission to assume the

“web-admin” Role• Those Users can assume the “web-admin” role and

then run and terminate web servers


What About Programmatic Users?


What About Programmatic Users?• Now, suppose I want an application to be able to

take actions — how can it do that?



take actions — how can it do that?• One common anti-pattern is to create a “User” and

save the User’s credentials somewhere the application can access them (for example, in a file)



take actions — how can it do that?• One common anti-pattern is to create a “User” and

save the User’s credentials somewhere the application can access them (for example, in a file)

• Don’t do this!!


What About Programmatic Users?


What About Programmatic Users?• Instead, use an Instance Profile to deliver Role

credentials to your applications



credentials to your applications• Role credentials are passed to the instance via the

Instance Profile automatically




Instance Profile automatically• Credentials are automatically rotated




Instance Profile automatically• Credentials are automatically rotated• No credentials in source repositories




Instance Profile automatically• Credentials are automatically rotated• No credentials in source repositories• Visibility into which Instances have which Roles


Use Cases


Use Cases• My web server needs access to an Amazon S3 bucket,

an Amazon SQS queue, and an Amazon SNS topic



an Amazon SQS queue, and an Amazon SNS topic• I need a cron job to be able to periodically take

snapshots of Amazon EBS volumes on my database servers





• My management server needs to be able to run, describe, and terminate instances





• My management server needs to be able to run, describe, and terminate instances

• My application needs to be able to describe the Instance it is running on in order to bootstrap itself


Roles for Amazon EC2 in 3 Steps


> Step 1: Create the Role







Step 1: Create the Role

> Step 2: Deploy the Role to an Instance







Step 1: Create the Role

Step 2: Deploy the Role to an Instance

> Step 3: Use the Role on the Instance





More on Instance Profiles

• Credentials are available via the instance metadata or available automatically through many AWS tools

• Processes on the instance can use the credentials to make API calls

• Easy way to avoid doing dumb things like checking in hard-coded credentials to source repositories


Additional Considerations

• Any process or user on the instance with access to the instance metadata can access the credentials

• Instances with Roles need to enforce their own access controls if users will have SSH access, etc.

• Role policies can be changed at any time, but Roles need to be added to instances at initial run time


Other Uses for Roles

• Beyond their usage in Instance Profiles, Roles can also help solve other identity and access problems

• Other AWS services can use Roles to take actions in your account subject to the Role’s policy

• Roles for cross-account access enable you to provide external parties access to your account

• You can let Users with Web Identities assume Roles to take actions in your account, too



Amazon EC2 Resource-level Permissions


Fine-Grained Authorization


Fine-Grained Authorization• Roles help me manage identities, but how do I

control what those identities can do?


Fine-Grained Authorization• Roles help me manage identities, but how do I

control what those identities can do?• Also, that “read-only” policy wasn’t very exciting —

how can I use these tools to do something more interesting?


Resource-level Permissions


Resource-level Permissions• Available for many AWS services, but we will focus

on Amazon EC2 resource-level permissions



on Amazon EC2 resource-level permissions• Enables fine-grained controls over individual

resources using an IAM policy




resources using an IAM policy• Enables controls over multiple resources based on

attributes of the resources using an IAM policy





attributes of the resources using an IAM policy• Supports tag-based authorization models





attributes of the resources using an IAM policy• Supports tag-based authorization models• Supports any IAM principal, including Roles


Sample Use Cases


Sample Use Cases• A User can start/stop/terminate certain instances


Sample Use Cases• A User can start/stop/terminate certain instances• A User can attach certain volumes to an instance


Sample Use Cases• A User can start/stop/terminate certain instances• A User can attach certain volumes to an instance• Only Admins can modify certain Security Groups


Sample Use Cases• A User can start/stop/terminate certain instances• A User can attach certain volumes to an instance• Only Admins can modify certain Security Groups• Segregate “prod” and “dev” resources and set

different permissions for each set of resources


Sample Use Cases• A User can start/stop/terminate certain instances• A User can attach certain volumes to an instance• Only Admins can modify certain Security Groups• Segregate “prod” and “dev” resources and set

different permissions for each set of resources• Make actions on sensitive resources conditional on

additional security steps, such as MFA


How does this work?


How does this work?• Resource-level permissions enable you to construct

fine-grained IAM policies



fine-grained IAM policies• Attach these policies to an IAM principal, i.e. “Bob”,

and the principal will be restricted by the policy




and the principal will be restricted by the policy• Policies are enforced at the API level, regardless of

whether Bob uses the console, tools, etc




and the principal will be restricted by the policy• Policies are enforced at the API level, regardless of

whether Bob uses the console, tools, etc• Policies are evaluated at runtime and will either allow

or deny the principal to perform a particular action


In Practice - Example 1


In Practice - Example 1• Suppose “Bob” should be able to stop one instance,

but not another — how do I enable this?


In Practice — Example 1


In Practice — Example 1• First, an administrator adds a resource-level policy

to “Bob” enabling him to stop only one particular instance






In Practice — Example 1• Once the policy has been applied, Bob tries to stop

the instance and succeeds



the instance and succeeds• If he tries to stop another instance, he gets an

authorization error






In Practice — Example 2• Now, suppose I have a lot of instances and I don’t

want to write a policy for each one



want to write a policy for each one• Allow Bob the ability to stop instances with the tag

“stack=dev”



want to write a policy for each one• Allow Bob the ability to stop instances with the tag

“stack=dev”• Deny Bob the ability to stop instances with the tag

“stack=prod”







the instance with the tag “stack=dev” and succeeds



the instance with the tag “stack=dev” and succeeds• If he tries to stop an instance with the tag

“stack=prod” then he gets an authorization error




How do these policies work?



• IAM Policies follow a “PARC” model:–Principal–Action–Resource–Conditions





• Principal:–The User, Group, or Role the policy is attached to

–For example, “Bob”





• Action:–The Action to be performed–Typically maps to an API Action–For example, “ec2:StopInstances”





• Resource:–The Resource involved in the Action–For example, Instance i-7216622f





• Conditions:–Optional additional parameters–For example, check for “ec2:ResourceTag/stack” : “dev”


{ "Statement":[{ "Effect":"effect", "Action":"action", "Resource":"arn" "Condition":{ "condition":{ "key":"value" } } } ]}





How do these policies work?• Policy definition and management is

provided by IAM• Actions, Resources, and many

Conditions are provided by services, such as Amazon EC2

• Documented by IAM and Amazon EC2


In Practice - Example 3


In Practice - Example 3• What about complex actions that involve multiple

resources?• Allow Bob to attach Volumes with the tag

“stack=dev” to Instances with the tag “stack=dev”




In Practice — Example 3• First, consult the documentation to determine which

resources and conditions are supported






In Practice — Example 3• Allows Bob to perform AttachVolume • The policy will apply to both Volumes and Instances • Both the Volume and Instances must have the tag

“stack=dev” on them






In Practice — Example 3• Bob can attach a Volume with the tag “stack=dev” to

an instance with the tag “stack=dev”• Bob cannot attach a Volume with the tag

“stack=prod” to an instance with the tag “stack=dev”




Best Practices• Develop an organization scheme for your resources

that makes sense for your use case• Tags are usually the best to organize resources • Rely on IAM’s default-deny model and focus on

writing minimally-permissive “Allow” policies• Test policies to ensure the behavior is as-expected


Additional Considerations• If you are using tags as a basis for permissions, the

tagging operations will now impact permissions and most users should not have access to them

• Not all Amazon EC2 operations currently support resource-level permissions, so consult the documentation liberally

• The same tags can be used for both permissions and tag-based billing



Coming Soon: Permissions for RunInstances


RunInstances Permissions• Control the AMIs and Snapshots “Bob” can use• Limit which Instance Types he can create• Limit the type and size of Volumes he can create• Limit which Subnets he can launch into• Limit which Security Groups he can launch into• Limit which Network Interface he can use• And more…



Iterating and Debugging


Dry-Run API Calls• Determines whether or not the API call would have

been authorized or not without actually processing it• Useful for verifying permissions for API calls like

TerminateInstances, where the result of the API call is potentially impactful

• Processed using the current state of the resource, just like regular API calls




Encoded Error Messages• Included in authorization denied errors

– EC2 API version 2013-06-15 and later

• Can be decoded using the AWS STS API DecodeAuthorizationMessage

• Includes information on the API call attempted and the policy applied

• AWS STS API can be locked down using IAM to provide an administrator/user separation of duties if desired




Putting it together• Create a test user with no permissions• Apply a policy to the test user• Make and API call as the test user with the Dry Run

flag enabled• Verify the behavior is as-expected• If not, inspect the Encoded Authorization Message• Adjust the policy as-needed and iterate



Additional Resources


Additional Resources


Additional Resources• Amazon EC2 User Guide

– “IAM Policies for EC2” – “IAM Roles”

• Amazon EC2 API Reference– “Permissions”

• Using IAM– “Permissions and Policies”– “Roles”

• AWS Security Blog


Please give us your feedback on this presentation

As a thank you, we will select prize winners daily for completed surveys!

CPN205 Thank You


Technology

Secure Amazon EC2 Environment with AWS IAM & Resource-Based Permissions (CPN205) | AWS re:Invent 2013