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

Securing Your Amazon EC2 Environment
with IAM Roles and Resource-Based Permissions
Derek Lyon, Principal Product Manager (AWS)
November 13, 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.
Friday, November 15, 13

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


Orientation


Orientation
• We’ll focus on authorization and credential issues in
order to address “Who can do what?” type problems


Orientation
• We’ll often speak at the API level, though the
approaches apply in the console and tools as well


Orientation
• We’ll assume you that have created Users and
Instances before, and likely a lot more than just that


Orientation
• 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 can be assumed by Users


What is a Role?
• Roles can also be passed to Instances


What is a Role?
• A User can only assume one Role at a time


What is a Role?
• Role permissions are established by policies


What is a Role?
• Role credentials have pre-set expiration times


What is a Role?
• 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 give the “web-admin” Role permission to run and
terminate web servers (and possibly more…)


A Simple Example
• I grant several Users permission to assume the
“web-admin” Role


A Simple Example
• 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?


• Now, suppose I want an application to be able to
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)


• 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!!


• Instead, use an Instance Profile to deliver Role
credentials to your applications


• Role credentials are passed to the instance via the
Instance Profile automatically


• Credentials are automatically rotated


• No credentials in source repositories


• 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


Use Cases
• I need a cron job to be able to periodically take
snapshots of Amazon EBS volumes on my database
servers


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


Use Cases
servers
• 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


• Roles help me manage identities, but how do I
control what those identities can do?


• 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


• Available for many AWS services, but we will focus
on Amazon EC2 resource-level permissions


• Enables fine-grained controls over individual
resources using an IAM policy


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


• Supports tag-based authorization models


• 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 attach certain volumes to an instance


Sample Use Cases
• Only Admins can modify certain Security Groups


Sample Use Cases
• Segregate “prod” and “dev” resources and set
different permissions for each set of resources


Sample Use Cases
• 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


How does this work?
• Attach these policies to an IAM principal, i.e. “Bob”,
and the principal will be restricted by the policy


How does this work?
• Policies are enforced at the API level, regardless of
whether Bob uses the console, tools, etc


How does this work?
• 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


• Suppose “Bob” should be able to stop one instance,
but not another — how do I enable this?


In Practice — Example 1


• First, an administrator adds a resource-level policy
to “Bob” enabling him to stop only one particular
instance


• 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


• Now, suppose I have a lot of instances and I don’t
want to write a policy for each one


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


• 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"
}
}
}
]



• 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

• 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”


• First, consult the documentation to determine which
resources and conditions are supported


• 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


• 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
• 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

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


Thank You

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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

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

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

Más de Amazon Web Services

Más de Amazon Web Services (20)

Último

Último (20)

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