AWS Solution Architect

Associate Exam Study

Notes: IAM (Identity and
Access Management)
By Matt Button |  Oct 2, 2017  | aws, aws-solution-architect-associate-exam
These notes were written while working through the A
Cloud Guru AWS Certified Solutions Architect - Associate
online course. These notes are partly from the videos, and
also from various other online sources. Primarily, they’re
notes for me, but you might find them useful too.
Since the AWS platform is changing so quickly, it’s
possible that some of these notes may be out of date, so
please take that into consideration if you are reading them.
Please let me know in the comments below if you have any
corrections or updates which you’d like me to add.
This post was last updated in March, 2019.
IAM (Identity and Access
Management)
FAQ
• Gives you centralised control of an AWS account
• Is global - there is no concept of regional IAM at this
time; all users, groups, policies, etc are available in all
regions.
• Supports Identity Federation which can be used for Single
Sign-on i.e. via SAML
• Can be used to give temporary access
IAM consists of Users, Groups Roles, and Policy
Documents
Users
Are the individual accounts.
By default, new users don’t have access to any AWS
services.
Always set up MFA (Multifactor Authentication) on your
root account.
IAM can be used to create and customise password rotation
policies.
There are two ways to access AWS:
• Username + Password
• Access Key ID + Secret Access Key
Username and Password
• Cannot be used to interact with the API
• Can be used to sign in via a custom sign-in link which
you can create via the IAM console i.e.

Access Key ID and Secret Access Key

• Assigned on user creation
• Can be used to interact via the AWS command line,
 SDKs, or APIs.
• Not the same as Username and Password.
• Can only be viewed once. If you lose them, they need to
be regenerated. Save them in a secure location.
Groups
Are a collection of IAM users, simplifying the assigning of
permissions. i.e. you can have groups for different
departments such as Sales, Developers, HR, etc, which may
all require different levels of AWS access.
• A user can belong to multiple groups
• Groups cannot belong to other groups
Roles
You can create roles, then assign them to AWS resources.
i.e. you might have an EC2 instance, and give it a role
saying it can access S3. That way the EC2 instance can
directly access S3 without having to manage usernames,
passwords, etc.
Limited to 500 IAM roles under your AWS account. The
acloud.guru course states up to 250.
Role types:
• AWS Service
• Another AWS Account (allows entities in other accounts
to perform actions in the current account)
• Web Identity (Amazon, Cognito, Facebook, Google)
• SAML / OpenID Connect
API Actions for assuming roles:
• AssumeRole
◦ You cannot call AssumeRole by using AWS root
account credentials; access is denied. You must
use credentials for an IAM user or an IAM role to
 call AssumeRole.
• AssumeRoleWithSAML - for when users have been
authenticated via a SAML authentication response, i.e.
an on-premises VPC
• AssumeRoleWithWebIdentity (when users have been
authenticated in a mobile app or web app with a web
identity provider suh as Facebook, Google, or OpenID
connect)
Including an IAM access policy with
AssumeRole
When assuming a role, you can futher restrict access via
passing an IAM access policy on each request.
If you pass a policy to this operation, the temporary
security credentials that are returned by the operation have:
• the permissions that are allowed by both the access policy
of the role that is being assumed
• and the policy that you pass.
… this gives you a way to further restrict the permissions
for the resulting temporary security credentials.
You cannot use the passed policy to grant permissions that
are in excess of those allowed by the access policy of the
role that is being assumed.
More info on STS API Operations
Policy Documents
An IAM policy is a document which formally defines
permissions, and can be attached to users, groups, and
roles.
The “ PowerUserAccess” policy provides full access to
AWS services and resources, but does not allow
management of users and groups.
For example, here’s one of the default AWS policy
documents for assigning full access to S3:

STS (Secure Token Service)

STS is used for requesting temporary, limited-privilege
credentials for AWS IAM users or for federated users
which you authenticate.
The temporary security credentials are valid for the
duration that you specified when calling AssumeRole,
which can be from 900 seconds (15 minutes) to a maximum
of 3600 seconds (1 hour). The default is 1 hour. More info
Supports the following sources:
• Federation (typically Active Directory)
◦ Uses SAML
◦ Allows you to use credentials from another provider
(i.e. Active Directory) - does not need to be IAM
credentials
◦ Does not need to be a user in IAM, or need any IAM
credentials
• Federation with mobile apps
◦ Using Facebook/Amazon/Google or other OpenID
provider to log in
• Cross-account access - allowing users from AWS account
to access resources in another
To use STS Federation, you must implement the following
steps in the following order:
1 Develop an Identity Broker to communiate with LDAP
(Lightweight Directory Access Protocol, one of the
protocols that you can use to talk to Active Directory)
and STS
2 Identity Broker always authenticates with LDAP first,
THEN with AWS STS
3 Application then gets temporary access to AWS resources
Web Identity Federation
Useful for mobile apps which need to access AWS
resources, and allows the app to aeceve an auth token, and
then use that token for temporary credentials.
It’s strongly recommended to not embed or distribute long-
term AWS credentials with apps that are user downloads to
a device.
Web Identity Federation supports the following providers:
• Amazon
• Facebook
• Google
• Any other OpenID Connect (OIDC) compatible id
provider