Evolving perimeters with guardrails, not gates: Improving developer agility - SDD331 - AWS re:Inforce 2019

© 2019,Amazon Web Services, Inc. or its affiliates. All rights reserved.
Evolving perimeters with guardrails, not gates:
Improving developer agility
Charlie Hammell
Principal Enterprise Architect
AWS
S D D 3 3 1
David Hocky
Cloud Solutions Architect
Comcast
Christopher Power
Cloud Solutions Architect
Comcast

Agenda
AWS Identity and Access Management (IAM) primer
Role assumption and identity federation
Permissions boundaries
AWS Organizations and Service Control Policies
Comcast’s governance journey and implementation
Federated user access experience
Enabling role management at scale with permissions boundaries
AWS Organizations and Service Control Policies in practice

Request
Actions, resources, principals,
environment data, resource data
IAM primer
Principals
Users
(and groups)
Roles
(assumed, delegated,
federated, service-linked)
Applications
Authentication
Resources
Authorization
Resource-based policies Other policies
(trust, permissions boundary)
Identity-based policies

AWS STS assume role
prod@example.com
Acct ID: 111122223333
ddb-role
dev@example.com
Acct ID: 123456789012
Call AWS APIs using
temporary security
credentials of ddb-role
IAM user: Alice
Get temporary
security credentials
for ddb-role
Authenticate with
Anders’ access keys
ddb-role trusts IAM users from the
AWS account dev@example.com (123456789012)
{ "Statement": [
{
"Effect":"Allow",
"Principal":{"AWS":"123456789012"},
"Action":"sts:AssumeRole"
}]}
Permissions assigned to Anders granting him permission
to assume ddb-role in account B
{ "Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/ddb-role"
}]}
Permissions assigned to ddb-role
{ "Statement": [
{ "Action":
[
"dynamodb:GetItem",
"dynamodb:BatchGetItem",
"dynamodb:DescribeTable",
"dynamodb:ListTables"
],
"Effect": "Allow",
"Resource":"arn:aws:dynamodb:us-east-1:
123456789012:table/books"
}]}
Books

User logs
in to portal
Corporate data center
Enterprise (identity provider) AWS (service provider)
Browser interface
Identity store
Identity
Provider
Portal
1
3
2
4
5
AWS sign-in
User
authenticated
Receive
response
(SAML
assertion)
Post the SAML assertion
to sign-in
Redirected to AWS
Management Console
Identity federation

Permissions boundary
Limit the maximum permissions of the principals created by delegated admins
• Certain IAM permissions
(such as PutUserPolicy and
AttachRolePolicy) were essentially
god-like
• Self-service permissions
management required non-trivial
automation
• Administrator can grant previously
god-like permissions, but specify a
permissions boundary
• Allows developers the ability to
create principals and attach
policies, but only within the
boundary

IAM-delegated administration
Account admin step 1: Create a permissions boundary policy preventing deletion of critical logs (CompanyBoundary)
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ServiceBoundaries",
"Effect": "Allow",
"Action": [
"s3:*",
"cloudwatch:*",
"ec2:*",
"dynamodb:*",
“lambda:*”,
"iam:ListUsers"
],
"Resource": "*"
},
{
"Sid": ”DenyProjectxyzS3Access",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::projectxyz",
"arn:aws:s3:::projectxyz/*"
]
}...

Account admin step 2: Create a permissions policy allowing the creation of IAM roles, but only if CompanyBoundary is specified;
attach permissions policy to delegated IAM admin principal
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"SetPermissionsBoundary",
"Effect":"Allow",
"Action":[
"iam:CreateRole",
"iam:AttachRolePolicy",
"iam:DetachRolePolicy"
],
"Resource":"arn:aws:iam::123456789012:role/AppRoles/*",
"Condition":{
"StringEquals":{
"iam:PermissionsBoundary":"arn:aws:iam::123456789012:policy/CompanyBoundary"
}
}
},
{
"Sid":"CreateAndEditPermissionsPolicy",
"Effect":"Allow",
"Action":[
"iam:CreatePolicy",
"iam:CreatePolicyVersion",
"iam:DeletePolicyVersion"
],
"Resource":"arn:aws:iam::123456789012:policy/AppPolicies/*"
}
]
}

Delegated IAM admin step 1: Create an IAM role specifying a path and a permissions boundary
aws iam create-role
--role-name MyTestAppRole
--path /AppRoles/
--permissions-boundary arn:aws:iam::123456789012:policy/CompanyBoundary
--assume-role-policy-document file://Role_Trust_Policy_Text.json
Delegated IAM admin step 2: Create a permissions policy allowing full access to Amazon S3
aws iam create-policy
--policy-name MyTestAppPermissions
--path /AppPolicies/
--policy-document file://MyTestAppPermissions.json
Delegated IAM admin step 3: Attach the policy to the newly created role
aws iam attach-role-policy
--role-name MyTestAppRole
--policy-arn arn:aws:iam::123456789012:policy/AppPolicies/MyTestAppPermissions
{
"Effect":"Allow",
"Action":"s3:*",
"Resource":"*"
}

Effective permission
Permission policy
{
"Effect":"Allow",
"Action":"s3:*",
"Resource":"*"
}
Permissions boundary
{
"Sid": "DenyProjectxyzS3Access",
"Effect": "Deny",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::projectxyz",
"arn:aws:s3:::projectxyz/*"
]
}...

Effective permission
Permissions
boundary
Permissions
policy
Allow: s3:* Allow: sqs:*
Allow: ec2:*Allow: ec2:*

A1 A3
M Master account
Organizational unit (OU)
Service control
policies (SCPs)
Dev Test Prod
AWS accountsA5A4A2 A7A6
AWS Organizations

SCPs
• Enable you to control which AWS service APIs are accessible
• Define the list of APIs that are allowed, or
• Define the list of APIs that must be blocked
• Cannot be overridden by local administrator
• Are necessary but not sufficient!
• Effective permission on IAM user/role is the intersection between the SCP and
assigned IAM permissions

AWS Organizations and permissions boundaries
sqs:*s3:*
ec2:*
sns:*
SCP
Permissions
boundary
Permissions policy

Policy evaluation
No
Deny evaluation:
Implicit deny, look for
an explicit deny
Yes
AWS Organizations
boundaries (SCP):
Is there an allow?
Yes
Principal boundaries
(permissions
boundaries):
Is there an allow?
Yes
AWS STS assume role
policies:
Is there an allow?
Yes
Permissions:
Is there an allow?
(identity-based,
resource-based)
Final decision allow

Connectingyoutowhatmatters
Comcast creates incredible
technology and entertainment
that connects millions of people
to the moments and experiences
that matter most.

Landscape

Guiding principles
Guardrails,
not gates
Developer
experience
Scalability
Security

Developer experience means
Agility
Ability to move quickly, scale, and change direction as necessary
Choice
Architecture, cloud services, and tooling that works for your team and use case
Native experience
Provide native access, and respect SDKs and tooling wherever possible
Support for modern development practices
Infrastructure as code, automation, CI/CD

Example
AWS Lambda
Amazon DynamoDBAmazon API Gateway
Client
Amazon CloudWatch AWS X-Ray
AWS Lambda
Role
RoleRole
User story
As a developer, I would like to
have an authenticated API that
reads properties from our
database so that I can present
relevant information to our
customers

What we want to avoid
AWS Lambda
Amazon DynamoDBAmazon API Gateway
User story
As a developer, I would like to
[submit a ticket so that I can] have
an authenticated API that reads
properties from our database so
that I can present relevant
information to our customers
[after I inevitably forget something
and have to open another ticket].
Client
Amazon CloudWatch AWS X-Ray
AWS Lambda
Role
RoleRole

Our governance toolkit
Third-party
software
Custom tooling
AWS IAM AWS CloudTrail AWS Config
Amazon GuardDuty
SSO
MFA token
AWS Organizations
Accounts

Advantages to identity federation
• Single sign-on for all federated users
• Integration with enterprise MFA
• Temporary access keys/secrets (max 12 hours)
• User lifecycle tied directly to HR systems
• Consistent user credentials across all AWS accounts
• Enables move from IAM users to IAM roles for people
Federated User Access
Single sign-on, MFA

Challengeswith identity federation
• Requires highly customized SAML claims generation
• Custom tooling required to get temporary credentials for API access
• Some systems do not support temporary credentials
• Need to have a solution to manage user to account access mapping

How Comcast is addressing these challenges
• Requires highly customized SAML claims generation
• Review published sample implementation by AWS for ADFS
• Have a supportive Directory Services team!
• Custom tooling required to get temporary credentials for API access
• Built Python and Golang based CLI utilities for MacOS, Linux, and Windows
• Supports ADFS + Azure MFA SAML sign-on flow
• Some systems do not support temporary credentials
• Limited issuance of IAM users for “service” accounts with audited credential rotation
• Still ticket driven
• Need to have a solution to manage user to account access mapping
• Developed portal and API for user management backed by Active Directory
• Enforces customized role-assignment business logic

Federated console access
• Single sign-on w/ MFA
• One URL to access console for all
AWS accounts
• Supports multiple accounts,
multiple roles

$ aws_login
Username: david
Password:
Waiting for MFA response
...
Please choose the role you would like to assume:
[ #]: [Account Alias] [Role Name] [AWS ARN]
[ 0]: 111122223333 Developer arn:aws:iam::111122223333:role/Developer
Selection: 0
----------------------------------------------------------------
Your new access key pair has been stored in the AWS configuration file ~/.aws/credentials under the
“saml” profile. To use this credential call the AWS CLI with the --profile option.
----------------------------------------------------------------
$ aws --profile saml sts get-caller-identity
{
"Account": "111122223333",
"UserId": "AROAXXXXXXXXXXXXX:david@domain.com",
"Arn": "arn:aws:sts::111122223333:assumed-role/Developer/david@domain.com"
}
Example federated CLI access

Role management evolution
Roles as tickets
Role vending
Native role creation

Role vending machine
AWS Lambda
Amazon API Gateway
Client AWS Lambda
AWS IAM
Role
AWS account
AWS account
AWS account
Permissions

Role: Developer (Federated)
Policies:
- PowerUserAccess
- RoleManager (Custom)
{ "Statement": [
{ "Action": [
"iam:AttachRolePolicy",
"iam:DetachRolePolicy"
],
"Effect": "Allow",
"Resource":[
"arn:aws:iam::123456789012:role/CustomRole/*
]",
"Condition": {
"ArnNotLike": {
"iam:PolicyARN":"arn:aws:iam::*:policy/Protect*"
}
}
},...]}
Role: CustomRole/MyTestRole (Vended)
Policies:
- ProtectPolicy (Custom)
{ "Statement": [
{ "Action": "iam:DetachRolePolicy"
"Effect": "Deny",
"Resource": "*",
"Condition": {
"ArnLike": {
"iam:PolicyARN": "arn:aws:iam::*:policy/Protect*"
}
}
}, other resource/service restrictions...]}
Example vended role protection
Beforepermissionsboundaries

Challengeswith role vending
• Requires thorough testing of code and policies
• Validation and error handling due to eventual consistency of IAM
• Roles need to be pre-created out-of-band before using them in AWS
• Cannot create roles with AWS Console & AWS Command Line Interface (AWS CLI)
• Breaks AWS Console wizards
• Difficult to integrate with Infrastructure-as-Code tooling such as
AWS CloudFormation and Terraform

• Requires thorough testing of code and policies
• Implement unit and integration tests
• Validation and error handling due to eventual consistency of IAM
• Treat role creation and policy attachment as a single transaction
• Roll-back on any step failure
• Roles need to be pre-created out-of-band before using them in AWS
• Publish internal documentation on role management
• Inner-sourced a custom Terraform provider for role vending API

Role vending works, but can we do better?
• Continued listening to app teams, focusing
on developer experience
• Agility, native experience, better support
for Infrastructure-as-Code
• How can we get there?
• … permissions boundaries

Advantages of permissions boundaries
• Native experience managing roles using AWS Console,
AWS CLI, AWS SDKs
• Less custom tooling, removes out-of-band role creation
• Supported by AWS CloudFormation and Terraform

Native role creation with permissions boundaries
Client AWS IAM
Role
AWS account
AWS account
AWS account
Permissions
AWS Management
Console

Permissions boundary at Comcast
Rolemanagement,adeveloper’sperspective
AWSTemplateFormatVersion: "2010-09-09"
Description: ”AWS IAM Role with Permissions Boundary"
Resources:
LambdaBasicExecutionRole:
Type: "AWS::IAM::Role"
Properties:
AssumeRolePolicyDocument:
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "sts:AssumeRole",
"Principal": { "Service": "lambda.amazonaws.com” },
"Effect": "Allow"
}
]
}
Path: "/Custom/"
RoleName: LambdaBasicExecutionRole
PermissionsBoundary: !Sub 'arn:aws:iam::${AWS::AccountId}:policy/Boundary’
ManagedPolicyArns:
- "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
Minimal changes to tooling required
1. Add governance
permissions boundary
2. Supply a role path or
namespace the role name

Challengeswith permissions boundaries
• (Still) requires thorough testing of policies
• Boundaries are limited to a single policy (6 KB)
• Policy simulator doesn’t support permissions boundaries
• AWS Console wizards do not support supplying or setting a default permissions
boundary

• (Still) requires thorough testing of policies
• Implement integration tests
• Boundaries are limited to a single policy (6 KB)
• Provide multiple boundaries depending on use case
• Move additional controls to AWS Organizations and SCPs
• Policy simulator doesn’t support permissions boundaries
• Add more integration tests to validate expected behavior

Boundaries based on graduated maturity model
Level 3
Level 2
Level 1
• Advanced users
• Certification required
• Intermediate users &
application developers,
CI/CD service roles
• Introductory users, least-
privilege service roles and
on-premise service users

AWS Organizations in Practice
• Consolidated cost view, billing, and controls
• AWS CloudTrail deployment
via service integration
• Account discovery framework
What we would like to see
• More service integrations
• Support for account metadata
• Improved account lifecycle management
Just Launched!

SCPs
• Protect resources and services
• Help simplify IAM policies in accounts
• Use to limit account access to services
Some limitations
• 5 SCPs per entity, 5 KB each
• Must be deliberate with design and use
• Wide blast radius

The experience today
• Account owners can easily add and remove users from AWS
accounts
• Individuals use the AWS Console & AWS CLI in any of their
AWS accounts with one set of credentials
• Security is happy because people are using federated single
sign-on and MFA to access AWS
• Teams can manage roles natively with AWS CloudFormation
and Terraform
• Leadership is happy because teams are more productive,
have choice, and can move with agility

What’s next?
SCPs
Expand use to simplify governance controls and permission boundaries
Expanded self-service SSO roles
Ability to customize federated login roles for different user personas
Launch self-service IAM users
Self-service access to manage service accounts for
access from on-premises deployments

Thank you!
Charlie Hammell
hammellc@amazon.com
David Hocky
david_hocky@comcast.com
Christopher Power
christopher_power@cable.comcast.com

Evolving perimeters with guardrails, not gates: Improving developer agility - SDD331 - AWS re:Inforce 2019

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Evolving perimeters with guardrails, not gates: Improving developer agility - SDD331 - AWS re:Inforce 2019

Similar to Evolving perimeters with guardrails, not gates: Improving developer agility - SDD331 - AWS re:Inforce 2019 (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Evolving perimeters with guardrails, not gates: Improving developer agility - SDD331 - AWS re:Inforce 2019