Deep dive into AWS IAM

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved
Deep dive into AWS IAM
Jesse Fuchs
Security Solutions Architect
Amazon Web Services
February 2019
Floor28

What to expect from this session
• AWS IAM core concepts
• Policy types
• Policy evaluation logic
• Boundary types
• Policy evaluation logic with boundaries

Considerations for layers of principals
Operating Systems
• Identities: Developers, and/or Systems Engineers
Applications
• Identities: Application Users, Application Administrators
Amazon Web Services
• Identities: Developers, Solutions Architects, Testers, Software/Platform
• Interaction of AWS Identities:
• Provisioning/deprovisioning EC2 instances and EBS storage.
• Configuring Elastic Load Balancers.
• Accessing S3 Objects or data in DynamoDB.
• Accessing data in DynamoDB.
• Interacting with SQS queues.
• Sending SNS notifications.
Amazon Web Services

Considerations for layers of principals
Operating Systems
• Identities: Developers, and/or Systems Engineers
Applications
• Identities: Application Users, Application Administrators
Amazon Web Services

AWS Principals
• Access to specific services.
• Access to console and/or APIs.
• Access to Customer Support (Business and Enterprise).
AWS Identity and Access Management (IAM)
• Access to all subscribed services.
• Access to billing.
• Access to console and APIs.
• Access to Customer Support.
Account Owner ID (Root Account)

AWS Identity and Access Management (IAM)
IAM Users IAM Groups IAM Roles Policies
Enables you to control who can do what in your AWS account

AWS IAM Policy Types
Identity-based policies Resource-based policies Access Control Lists

Policy
permission
categories
Policies
Identity-based
policies
Resource-
based policies
Access controls
lists (ACLs)
Principal (implicit)
Action
Resource
Condition
JSON-formatted documents
Attached to a principal (or identity)
Contains a statement (permissions)
that specifies:
• what actions that identity can
perform, on which resources, and
under what conditions.

Policy
permission
categories
Policies
Identity-based
policies
Resource-
based policies
Access controls
lists (ACLs)
Principal
Action
Resource
Condition
JSON-formatted documents
Attached to a resource
Contains a statement (permissions)
that specifies:
• what actions a specified principal can
perform on that resource under what
conditions.

Policy
permission
categories
Policies
Identity-based
policies
Resource-
based policies
Access controls
lists (ACLs)
Manage access to buckets and objects
Contains a Grantee and Permissions

AWS IAM Identity-Based Policy Example
AWS IAM
Identity-Based
Policy
AWS IAM User
(Alice)
"Version": "2012-10-17"
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::examplebucket/*"
}
]

AWS IAM Identity-Based Policy Example
AWS IAM
Identity-Based
Policy
AWS IAM User
(Alice)
"Version": "2012-10-17"
"Statement": [
{
"Effect": "Allow",
"Resource": "arn:aws:s3:::examplebucket/*”,
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/classification": ”sensitive"
}
}
]

AWS IAM Resource-Based Policy Example
AWS IAM
Resource-Based
Policy
Amazon S3 Bucket
"Version": "2012-10-17"
"Statement": [
{
"Effect": "Allow",
”Principal": {
"AWS" : "*"
},
"Resource": "arn:aws:s3:::examplebucket/*”
}
]

AWS IAM Resource-Based Policy Example
AWS IAM
Resource-Based
Policy
Amazon S3 Bucket
"Version": "2012-10-17"
"Statement": [
{
"Effect": "Allow",
”Principal": {
"AWS" : "*"
},
"Resource": "arn:aws:s3:::examplebucket/*”,
"Condition" : {
"IpAddress" : {
"aws:SourceIp": "192.168.143.0/24"
},
}
}
]

AWS IAM Policy Evaluation Logic
Decision
starts at Deny
Evaluate all
applicable
policies
Explicit
Deny?
• AWS retrieves all policies
associated with the user and
resource.
• Only policies that match the action
and conditions are evaluated.
No Explicit
Allow?
• By default, an
implicit (default)
deny is returned.
Final decision =“deny”
(default deny)
No
Final decision =“allow”
• Access is granted
if there is an
explicit allow and
no deny.
Yes
Final decision =“deny”
• If a policy statement
has a deny, it trumps
all other policy
statements.
Yes

AWS IAM Policy Evaluation Logic – Example 1
ACL
Identity-Based Policy
Resource-Based Policy
AWS IAM
Resource-Based
Policy
Amazon S3 Bucket
AWS IAM
Identity-Based
Policy
AWS IAM User
(Alice)
Effect: Allow
Action: s3:GetObject
Resource: *
Effect: Deny
Principal: *
Resource: *
Resulting Permission
X GetObject

(EC2 IAM Role)
(VPC Endpoint)
AWS IAM
Resource-Based
Policy
Amazon S3 Bucket
AWS IAM
Identity-Based
Policy
AWS IAM Role
(ARN 1)
Effect: Allow
Resource: *
Effect: Allow
Principal: *
Resource: *
GetObject
AWS EC2
Instance
AWS VPC Endpoint
(Gateway)
Effect: Allow
Principal: ARN 2
Action: *
Resource: *
X

(EC2 IAM Role)
AWS IAM
Identity-Based
Policy
AWS IAM Role
Effect: Allow
Resource: *
AWS Account 1
Trust
Relationship
AWS IAM Role
AWS Account 2
Effect: Allow
Principal: AWS Account 1
Action: sts:AssumeRole
Resource: *
AssumeRoleX

(EC2 IAM Role)
AWS IAM
Identity-Based
Policy
AWS IAM Role
Effect: Allow
Resource: *
AWS Account 1
Trust
Relationship
AWS IAM Role
AWS Account 2
Effect: Allow
Principal: AWS Account 1
Resource: *
AssumeRole
(Trust Relationship)

AWS IAM Boundary Types
Organization SCPs Permission Boundaries

Service Control Policies (SCPs)
Policy permission
categories
Boundaries
Organization
SCPs
Permission
Boundaries
• Enables you to control which AWS
service APIs are accessible.
- Define the list of APIs that are
allowed – whitelisting.
- Define the list of APIs that must
be blocked – blacklisting.
• Cannot be overridden by local
administrator.
• Resultant permission on IAM
user/role is the intersection between
the SCP and assigned IAM
permissions.

SCP Effective Permissions – Venn diagram
Service
Control
Policy
Identity-based
policies
Defined by
the admin
Defined by
the developer
Resulting
permission

Whitelisting ExampleBlacklisting Example
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
},
{
"Effect": "Deny",
"Action": ”cloudtrail:DeleteTrail",
"Resource": "*"
}
]
}
Service Control Policies (SCPs)
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"ec2:*”,
“redshift:*”,
“elasticache:*”
],
"Resource": "*"
}
]
}

Permission Boundaries
Mechanism to delegate the permission to create
users and/or roles while preventing privilege
escalation or unnecessarily broad permissions.
Method to safely grant actions like:
"iam:CreateRole"
"iam:PassRole"
Policy permission
categories
Boundaries
Organization
SCPs
Permission
Boundaries

Before and After Permission Boundaries
Before
• Certain IAM policy actions (e.g.
PutUserPolicy, AttachRolePolicy)
are essentially full admin-like
permissions.
• Doing any form of self-service
permissions management was
non-trivial.
Now
• Administrators can grant these full
admin-like permissions, but specify a
“permissions boundary.”
• Allows developers to create
principals for their applications and
attach policies, but only within the
boundary.

Use Cases
• Developers that need to create roles for Lambda functions
• Application owners that need to create roles for EC2 instances
• Admins that need to be able to create users for particular use cases
• Any others?

Just the facts
• Supported only for user and roles
• The mechanism at the policy level is just a condition context key
• Not all IAM actions support the condition context key
• It’s just a managed policy
• The user or role can do only the actions allowed by both the
attached identity-based policies and the permissions boundary

Requirement: users and roles
created by delegated admins must
have a permissions boundary
Ability: can create users and
roles that have permissions
boundaries attached
Admins
Delegated
admins
“Bound” IAM
users and roles
Create delegated admins Create “bound” users & roles
Users and roles
restricted by permissions
boundaries
Result: Permissions boundary
restrict the permissions of the
users and roles
Restricted
resources
Permissions for
resources restricted
Permissions of the roles attached
to resources like Lambda functions
are limited by the permissions
boundary
Role
Permissions
Lambda
Function Role
Permissions
Permission Boundary - workflow

An IAM condition context key
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary":
"arn:aws:iam::ACCOUNT_ID:policy/permissionboundary"
}
}

… applied to principal creation actions (users and roles)
"Effect": "Allow",
"Action": [ "iam:CreateRole” ],
"Resource": [ "arn:aws:iam::ACCOUNT_ID:role/path/” ],
"Condition": {
"StringEquals": {
"iam:PermissionsBoundary":
"arn:aws:iam::ACCOUNT_ID:policy/permissionboundary"
}
}

But, it’s just an IAM policy right?
IAM policy
Identity-based policy slot
Identity-based
policy
Permissions
boundary
Permissions boundary slot
IAM
role

But, it’s just an IAM policy right?
Identity-based policy slot
Permissions boundary slot

AWS IAM Delegated Administration – Demo
• User requirements:
• Lambda function that reads from an S3 bucket
• Lambda function must have an IAM role to access the bucket
• Role must be created with the correct permissions
• Company requirements:
• Policies attached to the role must not allow privilege escalation or unneeded permissions
• Don’t get in the way of the user
Admin
Delegated
admin
Create:
Policy for a user (plus read only policies)
Permissions boundary policy
User
Lambda function
Lambda function
restricted by permissions
boundary
Lambda
Function Role
Permissions
Create:
Policy for a role
Role
Lambda function
https://awssecworkshops.com/

1. Authenticate the principal
2. Determine which policies apply to the request
3. Evaluate the different policy types that apply which affect the
order in which they are evaluated.
4. Allow or Deny the request
Everything after authentication

PB Effective Permissions – Venn diagram
Permissions
boundary
Identity-based
policies
Defined by
the admin
Defined by
the developer
Resulting
permission

Effective permissions – mechanism
API
Request
Request
allowed
Identity-based
policy
Explicit
deny

Identity-based
policy
Explicit
deny
API
Request
Permissions
boundary
Resulting permission
Request
allowed

API
Request
Implicit
deny
Explicit
deny
Allow
Implicit
deny
Allow
Identity-based
policy
Explicit
deny
Permissions
boundary

Effective permissions – allow example
API
Request
Allow Allow
Request
allowed
Identity-based
policy
Explicit
deny
Permissions
boundary

Effective permissions – scenario 1
Identity-based PolicyPermissions boundary
Request: s3:GetObject / bucket name: example1
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream”,
"logs:PutLogEvents”
],
"Resource": "arn:aws:logs:*:*:*"
}
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:CreateLogStream",
"logs:PutLogEvents",
"s3:*"
],
"Resource": "*"
}
]
}

Effective permissions – result
API
Request:
s3:getobject Allow
Request
DeniedImplicit
deny
Identity-based
policy
Explicit
deny
Permissions
boundary

API
Request:
s3:getobject Allow
Request
DeniedImplicit
deny
Identity-based
policy 2
Explicit
deny
Permissions
boundary
Identity-based
policy 1

Identity-based Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": "*"
}
]
}
Permissions boundary
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
],
},
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource”:"arn:aws:s3:::example1/*"
}
}

API
Request:
s3:getobject Allow
Request
allowed
Allow
Identity-based
policy
Explicit
deny
Permissions
boundary

Identity-based Policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
],
"Resource": "*"
}
]
}
Permissions boundary
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
],
},
{
"Effect": "Allow",
"Action": ["s3:GetObject"],
"Resource”:"arn:aws:s3:::example1/*"
}
}

API
Request:
s3:getobject Implicit
deny
Request
denied
Allow
Identity-based
policy
Explicit
deny
Permissions
boundary

AWS IAM Policy Prioritization with Boundaries
Resulting
permission
Permissions
boundary
Identity-based
policy
Service control
policy
Session
policy

Identity-based
policy
Explicit
deny
API
Request
Permissions
boundary
SCPs Session
Policy
Request
allowed
Resource-
based policy
AWS Account

Explicit
deny
API
Request
Request
allowed
Resource-
based policy
AWS Account 1 (outside of OU) AWS Account 2
Full evaluation of
all applicable
policies

AWS IAM Policy Categories
Policy
permission
categories
Boundaries
Organization
SCPs
Permission
Boundaries
Policies
Identity-based
policies
Resource-based
policies
Access controls
lists (ACLs)

Thank You!
Floor28

Deep dive into AWS IAM

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Deep dive into AWS IAM

Similar to Deep dive into AWS IAM (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Deep dive into AWS IAM