2. Agenda / Topics
• Basics
o What is IAM?
o What to do right after creating an AWS account
o What are the main components of IAM?
• What not to do
o Don’t be that person / company…
• Intermediate
o Least privilege access permissions
o How to manage / distribute AWS creds
o How to write code that auto-discovers AWS creds
o AWS Services that support IAM and at what level
• Advanced
o Temporary credentials / Avoiding long-lived creds
o AWS account federation / SSO
3. What is AWS IAM?
• Identity and Access Management is an AWS service
that enables you to provide fine grained access
control to:
o Interact with AWS services on behalf of your AWS account
o Interact with AWS resources created in your AWS account
• The main components are:
o IAM Users
o IAM Groups
o IAM Roles
o IAM Polices
4. IAM Users
• Can have username / password to login to the AWS
Console
• Can have AWS credentials for making API calls to
interact with AWS services
• New IAM users have no permissions to do anything,
implicit deny all. Permissions must be explicitly
granted.
• An IAM user doesn't necessarily have to represent
an actual person. An IAM user is really just an
identity with associated permission.
o An IAM User with only AWS creds can be created so the creds can be
used by an application to make API calls into AWS.
5. IAM Groups
• A collection of IAM Users
• You assign permissions to the IAM Group, all IAM
Users in the Group inherit those permissions.
o Implicit deny of permissions applies to IAM Groups as well
6. IAM Roles / Instance Profiles
• IAM Roles define permissions much like an IAM User
o IAM Roles do NOT have:
• Username/password like an IAM User can
• AWS creds that can be retrieved like an IAM User creds
• The permissions of an IAM Role can be granted /
assigned to an EC2 instance
o An Instance Profile is just a “container” for one or more IAM Roles
o An Instance Profile is what you actually assign to an EC2 instance
• IAM Roles and Instance Profiles provide enhanced
security because these structures provide
temporary AWS creds
o These temporary creds are made available by the EC2 meta-data service
• … More on IAM Roles later
7. IAM Policies
• When you create an IAM Group, User, or Role in
your AWS account, you associate an IAM policy
with it, which specifies the permissions that you want
to grant.
• IAM Polices are JSON formatted documents that
define AWS permissions
• Working with IAM Policies
8. Security firsts for new
AWS accounts
• For AWS root account:
o Store username/password somewhere safe and secure
o Setup multi-factor authentication
• Create IAM User(s) with "least privileges" necessary
o Least privilege = only the permissions necessary to accomplish needed tasks
• After IAM Users have been created never use root
account again
o An IAM User with root permissions can be created
• If IAM Users have username/password for AWS console
login then they should also have multi factor
authentication (MFA) enabled
o https://aws.amazon.com/iam/details/mfa/
• If you don’t want some users having access to billing
o Control access to AWS account billing through IAM
• IAM controls “the keys to the (AWS) kingdom”
o Only highly privileged users should have permissions to perform IAM actions
9. Getting AWS credentials
onto EC2 instances
• Always use an IAM Role / Instance Profile
• Never ever..... ever
o Self manage credentials for EC2 instances (environment variables, etc)
o Put AWS credentials into source code or config files
• Don't make yourself or company a victim like these
guys:
o Key slurping bots crawl github, use creds to run EC2 instances for bitcoin
mining
• http://www.theregister.co.uk/2015/01/06/dev_blunder_shows_github_
crawling_with_keyslurping_bots
o Companies have gone out of business because they were careless with
their AWS creds
• CodeSpaces had EVERYTHING deleted
o http://arstechnica.com/security/2014/06/aws-console-breach-
leads-to-demise-of-service-with-proven-backup-plan/
10. …continued
Getting creds onto EC2 instances
• Use IAM Instance Profile assigned to EC2 instance
• An Instance Profile is created from an IAM Role
• The instance profile must be assigned to an EC2 instance
when it is launched
• AWS credentials retrieved through the EC2 metadata service
o curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<instance-
profile-name>
• These temporary credentials never have to be shared or
managed by developers
• These temporary AWS credentials are automatically rotated so
instance always has valid credentials
• http://docs.aws.amazon.com/IAM/latest/UserGuide/roles-
usingrole-instanceprofile.html
• http://docs.aws.amazon.com/IAM/latest/UserGuide/roles-
usingrole-ec2instance.html
11. How can code use
Instance Profile creds?
• All AWS SDKs have a built in way to auto-discover AWS
credentials on EC2 instances
o Simplifies code by not having to explicitly set AWS credentials
• SDKs for all languages can automatically check
standard locations for AWS credentials to use:
o Environment Variables - AWS_ACCESS_KEY_ID and AWS_SECRET_KEY (legacy,
not recommended anymore)
o Credentials file at the default location (~/.aws/credentials) shared by all AWS
SDKs and the AWS CLI (great for applications/scripts being run outside of AWS)
o Instance Profile Credentials - delivered through the Amazon EC2 metadata
service (best practice for getting AWS creds onto EC2 instances)
• Example - Java SDK docs which document AWS creds
auto-discovery:
o http://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws
/services/s3/AmazonS3Client.html - AmazonS3Client()
12. Local development
• If you are running scripts or an application locally that
needs to call AWS APIs then store AWS creds in the AWS
“credentials” file:
o http://blogs.aws.amazon.com/security/post/Tx3D6U6WSFGOK2H/A-New-and-
Standardized-Way-to-Manage-Credentials-in-the-AWS-SDKs
• Allows you to define multiple sets of credentials each
identified by a profile name
• A “default” profile name can be defined so a profile
doesn’t have to be specified in your code/script
• AWS CLI (command line interface)
o http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-
started.html#cli-multiple-profiles
o aws s3 cp ./awesome.tgz s3://mybucket/path/to/awesome/files/ (uses default
profile defined in ~/.aws/credentials file)
o aws s3 cp ./awesome.tgz s3://mybucket/path/to/awesome/files/ --profile user2
(uses user2 profile defined in ~/.aws/credentials file)
13. IAM least privilege rights
• "Anything" with AWS access should have the
minimal rights it needs to accomplish its specific
actions
• "Anything" with AWS access refers to the following:
o IAM Users or Groups
o IAM Roles / Instance Profiles
• IAM Roles can be assumed by end users
• Instance Profiles can be assigned to EC2 instances
o Your applications or scripts (which use IAM Role or User creds)
• Example: if an application only needs read access
to files in S3, then create an IAM Role with only
“GetObject” rights on S3.
14. S3 IAM Policies
• Granting access to an S3 bucket (Simple)
• Granting access to specific “folders” in S3 bucket
• S3 Actions
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::test"]
},
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": ["arn:aws:s3:::test/*"]
}
]
}
15. Amazon Resource Names
(ARNs)
• ARNs are unique identifiers for AWS resources.
• Format of an ARN:
o arn:partition:service:region:account-id:resource
o arn:partition:service:region:account-id:resourcetype/resource
o arn:partition:service:region:account-id:resourcetype:resource
• Details of ARNs for each AWS Service
o http://docs.aws.amazon.com/general/latest/gr/aws-arns-and-
namespaces.html
16. Elements of an IAM
Policy
• Main elements of an IAM Policy
o Version
o Statement
• Main element of the policy
• Contains an array of statements
• Each statement defines whether permissions are allowed or denied
for certain service actions against particular resources. These are
defined by the values of the following elements in each statement:
o Effect – Allow or Deny
o Action – array of service actions
o Resource – array of ARNs that actions can occur on
o Principal – identifies who/what is allowed/denied access
• Details on IAM Policy elements
o http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_e
lements.html
17. Advanced uses of
IAM Roles
• IAM Roles can be “assumed” by:
o IAM Users in the either the same or different AWS account
o AWS services (EC2 instances or even another IAM Role)
o External users authenticated outside of AWS (Federation)
• IAM Roles provide enhanced security:
o Temporary credentials
• If credentials do get compromised they won’t be valid for long
• “Long-lived” credentials are bad… mmmmmkkk
o Users can be logged into AWS console without username/password
o Temporary credentials + Least privilege permissions!!!
18. AWS Federation
• My real world scenario
o Many AWS accounts
o Many users needing access to 1 or many AWS accounts
o Management of many of the “same” IAM Users and Groups across many
AWS accounts
• Equals…
o Maintenance nightmare
o Potential for security lapses when employee leaves company
• What AWS accounts did the employee have access to?
• Have to delete IAM User from each AWS account
• Most mid to large companies have a central
Identity Provider
o Active Directory
o Federation could also use social login providers
19. …continued
AWS Federation
• We took a web application that uses SSO via SAML to authenticate with
our corp AD
o Runs in AWS on EC2 instance with Instance Profile that has rights to “assume” Roles
o The IAM Roles that can be “assumed” can exist in any AWS account as long as a trust relationship is
created.
o IAM Roles are kept track of in the application DB
o For each user of this web application 0 or more IAM Roles can be mapped to a user
o The application can then retrieve temporary credentials from a Role on behalf of a user of the web
application
• AWS creds can be returned to user for local use
• AWS console access can be granted based on permissions of the IAM Role
• Simplified solution
o Delete all IAM Users across all AWS accounts
o Replace all IAM Groups with IAM Roles in each AWS account
o One set of users (web application users) that can be granted access to any IAM Role from any AWS
account.
o Enhances security
• If a user leaves the company they are removed from corporate AD, no longer have access to web
application and therefore no more access to any AWS accounts
• TEMPORARY AWS creds (only last 1 hour, AWS allowed max… for now)
• Creating a URL that Enables Federated Access to the AWS Management
Console
o Java example code
20. AWS Console
Federated Username
• Federated Login/Identifier uses the name of the IAM Role
that was used plus a specified identifier.
• It is cutoff in this image
• AutomationFederationRoles-AutomationAdmins-1VGJS9PG5J8JO/erik.paulsson
21. AWS Federation
Local dev with temp creds
• It is a pain for developers and cloud admins to work locally
when AWS creds expire
o Every hour have to:
• Retrieve new AWS creds from web application
• Copy/paste into local AWS credentials file
• Solution
o Wrote small GUI tool
• Local thick client since it needs to write to file system
• User authenticates to same web application using SSO still
• Tool retrieves new credentials on hourly schedule from web application REST
APIs
• Writes these AWS credentials to local AWS credentials file
o Tool allows users to retrieve creds for 0 or more of the IAM Roles they are
allowed to use
o A credentials profile name can be assigned to each
o Used NW.js to build client (formerly known as “node-webkit”)
• Single code base
• Compiles to self executable for all platforms (Linux, Mac, Win)
• No run-time dependencies (JRE, python, etc)
o Just download and run
22. Other Links
• Advanced Assume Role using “policy” parameter:
o http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.h
tml
• IDC White Paper: You can be more secure in the
cloud than in your own data center
• AWS in Plain English
o https://www.expeditedssl.com/aws-in-plain-english