Are you interested in becoming an expert in managing access to your AWS resources? Have you ever wondered how to best scope down permissions for least privilege access? Do you have multiple AWS accounts and need to know how to manage access to resources centrally? In this session, we take an in-depth look at AWS Identity and Access Management (IAM) and AWS Organizations. You will learn how to quickly create IAM policies to manage fine-grained access to your resources. Throughout the session, we will cover common use cases, such as how to grant a user access to an Amazon S3 bucket or permissions to launch an Amazon EC2 instance of a specific type. You will also learn how to create and use Service Control Policies (SCPs) through Organizations to manage AWS service use across all your accounts centrally.
4. What to expect from the session
• Knowledge of how to better control
access to AWS resources.
• A deeper understanding of the AWS
policy language.
• Tips for avoiding common mistakes.
• Insights into using AWS Organizations
together with IAM.
• A closed-loop process for authoring,
debugging, and validating policies.
5. Your first day as an IAM administrator
• Scenario: A user at your company has overly permissive
Amazon EC2 privileges. He keeps launching
unnecessarily large instance types.
• Goal: Create a new policy that allows him to control EC2
instances, but only launch instances of specific types:
• t1.*, t2.*, m3.*
10. Principal – Examples
• An entity that is allowed or denied access to a resource
• Indicated by an Amazon Resource Name (ARN)
• With IAM policies, the principal element is implicit (i.e., the user, group, or role attached)
<!-- Everyone (anonymous users) -->
"Principal":"AWS":"*.*"
<!-- Specific account or accounts -->
"Principal":{"AWS":"arn:aws:iam::123456789012:root" }
"Principal":{"AWS":"123456789012"}
<!-- Individual IAM user -->
"Principal":"AWS":"arn:aws:iam::123456789012:user/username"
<!-- Federated user (using web identity federation) -->
"Principal":{"Federated":"accounts.google.com"}
<!-- Specific role -->
"Principal":{"AWS":"arn:aws:iam::123456789012:role/rolename"}
<!-- Specific service -->
"Principal":{"Service":"ec2.amazonaws.com"}
Principal
Action
Resource
Condition
11. Principal – Examples
• An entity that is allowed or denied access to a resource
• Indicated by an Amazon Resource Name (ARN)
• With IAM policies, the principal element is implicit (i.e., the user, group, or role attached)
<!-- Everyone (anonymous users) -->
"Principal":"AWS":"*.*"
<!-- Specific account or accounts -->
"Principal":{"AWS":"arn:aws:iam::123456789012:root" }
"Principal":{"AWS":"123456789012"}
<!-- Individual IAM user -->
"Principal":"AWS":"arn:aws:iam::123456789012:user/username"
<!-- Federated user (using web identity federation) -->
"Principal":{"Federated":"accounts.google.com"}
<!-- Specific role -->
"Principal":{"AWS":"arn:aws:iam::123456789012:role/rolename"}
<!-- Specific service -->
"Principal":{"Service":"ec2.amazonaws.com"}
Replace
with your
account
number
Principal
Action
Resource
Condition
12. Action – Examples
• Describes the type of access that should be allowed or denied
• You can find actions in the docs or use the policy editor to get a drop-down list
• Statements must include either an Action or NotAction element
<!-- EC2 action -->
"Action":"ec2:StartInstances"
<!-- IAM action -->
"Action":"iam:ChangePassword"
<!– Amazon S3 action -->
"Action":"s3:GetObject"
<!-- Specify multiple values for the Action element-->
"Action":["sqs:SendMessage","sqs:ReceiveMessage"]
<-- Wildcards (* or ?) in the action name. Below covers create/delete/list/update-->
"Action":"iam:*AccessKey*"
Principal
Action
Resource
Condition
13. Understanding NotAction
• Lets you specify an exception to a list of actions
• Could result in shorter policies than using Action and exclude many actions
• Example: Let’s say you want to allow everything but IAM APIs
{
"Version": "2012-10-17",
"Statement": [ {
"Effect": "Allow",
"NotAction": "iam:*",
"Resource": "*"
}
]
}
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "iam:*",
"Resource": "*"
}
]
}
or
Is there a
difference?
14. Understanding NotAction
• Lets you specify an exception to a list of actions
• Could result in shorter policies than using Action and exclude many actions
• Example: Let’s say you want to allow everything but IAM APIs
{
"Version": "2012-10-17",
"Statement": [ {
"Effect": "Allow",
"NotAction": "iam:*",
"Resource": "*"
}
]
}
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": "iam:*",
"Resource": "*"
}
]
}
or
This is not a Deny. A user could still have a
separate policy that grants IAM:*
If you want to prevent the user from ever being
able to call IAM APIs, use an explicit Deny.
Is there a
difference?
15. Resource – Examples
• The object or objects being requested
• Statements must include either a Resource or a NotResource element
<-- S3 bucket -->
"Resource":"arn:aws:s3:::my_corporate_bucket/*"
<-- All S3 buckets, except this one -->
"NotResource":"arn:aws:s3:::security_logging_bucket/*"
<-- Amazon SQS queue-->
"Resource":"arn:aws:sqs:us-west-2:123456789012:queue1"
<-- Multiple Amazon DynamoDB tables -->
"Resource":["arn:aws:dynamodb:us-west-2:123456789012:table/books_table",
"arn:aws:dynamodb:us-west-2:123456789012:table/magazines_table"]
<-- All EC2 instances for an account in a region -->
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"
Principal
Action
Resource
Condition
16. Resource – Examples
• The object or objects being requested
• Statements must include either a Resource or a NotResource element
<-- S3 bucket -->
"Resource":"arn:aws:s3:::my_corporate_bucket/*"
<-- All S3 buckets, except this one -->
"NotResource":"arn:aws:s3:::security_logging_bucket/*"
<-- Amazon SQS queue-->
"Resource":"arn:aws:sqs:us-west-2:123456789012:queue1"
<-- Multiple Amazon DynamoDB tables -->
"Resource":["arn:aws:dynamodb:us-west-2:123456789012:table/books_table",
"arn:aws:dynamodb:us-west-2:123456789012:table/magazines_table"]
<-- All EC2 instances for an account in a region -->
"Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*"
Principal
Action
Resource
Condition
Replace
with your
account
number
17. Condition example
“Condition” : {
"DateGreaterThan" : {"aws:CurrentTime" : "2017-01-01T11:00:00Z"},
"DateLessThan": {"aws:CurrentTime" : "2017-12-31T15:00:00Z"},
"IpAddress" : {"aws:SourceIp" : ["192.0.2.0/24", "203.0.113.0/24"]}
}
• Allows a user to access a resource under the following conditions:
• The time is after 11:00 A.M. on 01/01/2017 AND
• The time is before 3:00 P.M. on 12/31/2017 AND
• The request comes from an IP address in the 192.0.2.0 /24 OR 203.0.113.0 /24
range
• All of these conditions must be met in order for the statement to evaluate to TRUE.
AND
OR
What if you wanted to restrict access to a time frame and IP address range?
Principal
Action
Resource
Condition
18. Take advantage of IfExists conditional operator
• Many condition keys only exist for certain resource
types.
• If you test for a nonexistent key, your policy will fail to
evaluate (in other words, access denied).
• You can add IfExists at the end of any condition
operator except the Null condition (for example,
StringLikeIfExists).
• Allows you to create policies that “don’t care” if the key is
not present.
19. Take advantage of IfExists conditional operator
• Many condition keys only exist for certain resource
types.
• If you test for a nonexistent key, your policy will fail to
evaluate (in other words, access denied).
• You can add IfExists at the end of any condition
operator except the Null condition (for example,
StringLikeIfExists).
• Allows you to create policies that “don’t care” if the key is
not present.
Serious Ninja-foo
21. Policy variables
• Predefined variables based on service request context
• Global keys (aws:SourceIP,
aws:MultiFactorAuthPresent, etc.)
• Principal-specific keys (aws:username, aws:userid,
aws:PrincipalType)
• Provider-specific keys (graph.facebook.com:id,
www.amazon.com:user_id)
• SAML keys (saml:cn, saml:edupersonassurance)
• See documentation for service-specific variables
• Benefits
• Simplify policy management
• Reduce the need for hard-coded, user-specific policies
22. {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::myBucket"],
"Condition":
{"StringLike":
{"s3:prefix":["home/${aws:username}/*"]}
}
},
{
"Effect":"Allow",
"Action":["s3:*"],
"Resource": ["arn:aws:s3:::myBucket/home/${aws:username}",
"arn:aws:s3:::myBucket/home/${aws:username}/*"]
}
]
}
The anatomy of a policy with variables
Grants a user access to a home directory in S3 that can be accessed programmatically
23. {
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::myBucket"],
"Condition":
{"StringLike":
{"s3:prefix":["home/${aws:username}/*"]}
}
},
{
"Effect":"Allow",
"Action":["s3:*"],
"Resource": ["arn:aws:s3:::myBucket/home/${aws:username}",
"arn:aws:s3:::myBucket/home/${aws:username}/*"]
}
]
}
The anatomy of a policy with variables
Grants a user access to a home directory in S3 that can be accessed programmatically
Version is required
Variable in conditions
Variable in resource ARNs
25. Policy enforcement
Final decision =“Deny”
(explicit Deny)
Yes
Final decision =“Allow”
Yes
No Is there an
Allow?
4
Decision
starts at Deny
1
Evaluate all
applicable
policies
2
Is there an
explicit
Deny?
3
No Final decision =“Deny”
(default Deny)
5
• AWS retrieves all policies
associated with the user and
resource.
• Only policies that match the action
and conditions are evaluated.
• If a policy statement
has a Deny, it trumps
all other policy
statements.
• Access is granted
if there is an
explicit Allow and
no Deny.
• By default, an
implicit (default)
Deny is returned.
27. Demo: Controlling access to EC2
• Goal: Create a policy that allows users to control EC2
instances, but:
• Only launch instances of specific types.
• Only launch instances in two specific regions.
• We’ll examine how to:
• Create an inline policy.
• Enable users to access the EC2 console.
• Use policy conditions to limit the users to the specified types
and regions.
34. Today
Jump
account
Your cloud team
Dev account
Prod account
Data science
account
Security account
Cross-
account
trusts
Cross-account
resource access
You
35. Create account hierarchy and apply policies
A6
Development Test Production
A8A1
A5
A4A3
A2
A9
A7
Root
Service Control Policies use the same policy language, but
only specify Actions
36. SCPs are necessary but not sufficient
Allow: S3:* Allow: SQS:*
Allow: EC2:*Allow: EC2:*
SCP IAM
permissions
37. SCPs are necessary but not sufficient
Allow: EC2:*Allow: S3:* Allow: SQS:*
SCP IAM
permissions
39. Demo: Implementing VPC guardrails
• Goal: Create a policy that ensures that no one can
attach an Internet gateway to a development VPC.
• We’ll examine how to:
• Use job function policies to grant common sets of privileges.
• Use explicit Deny in IAM policies to control sensitive actions.
• Create a managed policy and attach it to all the principals.
• Use an SCP to achieve the same result, but across multiple
accounts.
43. Demo: Implementing VPC guardrails
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ec2:AttachInternetGateway",
"ec2:CreateInternetGateway"
],
"Resource": [
"*"
]
}
]
}
Basic policy hygiene
Explicit Deny
Specific actions we are trying to
control
For SCP use,
Allow comes from
companion policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
44. A mechanism for AWS policies
Verbalize
Author
Validate &
simulate
Deploy
Continuously
monitor
Iterate
“Good intentions don’t
work—mechanisms work.”
-- Jeff Bezos
45. A mechanism for AWS policies
Demo
Verbalize
Author
Validate &
simulate
Deploy
Continuously
monitor
Iterate
46. Demo: A mechanism for AWS policies
Verbalize
Author
Validate &
simulate
Deploy
Continuously
monitor
Iterate
“I want to create a policy for my advanced
DevOps group that allows broad AWS
access, except for IAM and AWS
CloudTrail. Because this is the production
web account, they should also not have
access to Amazon WorkSpaces.”
48. Demo: A mechanism for AWS policies
Verbalize
Author
Validate &
simulate
Deploy
Continuously
monitor
Iterate
#!/usr/bin/python
principalstocheck = [ 'arn:aws:iam::123456789012:user/milton',
'arn:aws:iam::123456789012:user/peter' ]
actionstocheck = [ 'iam:AddRoleToInstanceProfile',
<snip>
'cloudtrail:StopLogging',
<snip>
'workspaces:TerminateWorkspaces' ]
with open(opts['--policy']) as policy_file:
policy = policy_file.read()
for principal in principalstocheck:
simulationdict = client.simulate_principal_policy(
PolicySourceArn=principal,ActionNames=actionstocheck,
PolicyInputList=[policy])
evalresults = simulationdict['EvaluationResults']
for evalresult in evalresults:
evaldecision = evalresult['EvalDecision']
if (evaldecision == 'allowed'):
print ‘Found an allowed action, your policy needs work!’
49. Demo: A mechanism for AWS policies
Verbalize
Author
Validate &
simulate
Deploy
Continuously
monitor
Iterate
AWS Config
Event notifications
of IAM changes
AWS Lambda
Executes policy
simulation checks
Amazon SNS
Notifications of findings
(same code from
simulate)
(human or fully
automated)
Check out SEC311: How to Automate Policy Validation
from re:Invent 2016 for code samples & more details
50. IAM Policy Ninja
Disclaimer: Not really. This is not a real certification, but thank you for staying until the end.