IAM
Principals
- Principal
-
- IAM entity that is allowed to interact with AWS resources
- Can be permanent/temporary
- Can represent human/application
Types
Type |
Description |
ROOT USER |
Complete access to the account |
IAM USERS |
Persistent entities representing people/apps |
ROLES/STS |
- Roles are used to grant specific PRIVILEGES to specific ACTORS for a SET DURATION OF TIME
- When actor assumes a role → AWS gives him a temporary security token from STS (Security Token Service)
- Expiration needs to be specified when requesting an STS token (15mins - 36h)
- Actors can be authenticated against AWS or some trusted external service
- Use Cases
- Federated (non-AWS) user access (see below)
- Cross-Account Access: setup roles to provide users who have permissions in 1 account to access resources under another account
- SAML 2.0
- Create trust between your org Identity Provider (IdP) & other orgs as Service Providers
- Configure AWS as the Service Provider & use SAML to provide users with federated SSO to AWS Console
- EC2 Roles (grant permissions to apps running on EC2) → no fixed access key that must be rotated
|
Authentication
Type |
Description |
Username/Password |
Human principals |
Access Key |
- Application principals
ACCESS KEY ID (20chars) + ACCESS SECRET KEY (40chars)
|
Access Key with Session Token |
- Process operating under an assumed role
TEMPORARY TOKEN = ACCESS KEY (2 parts) + SESSION TOKEN
|
- Users
Admin user
= access to everything apart from billing
Power user
= access to everything except IAM
- Multifactor
- Root user can recover from lost second factor by verifying email address + phone number ownership
- APIs can require it by adding condition statements (
aws:MultiFactorAuthPresent
, aws:MultiFactorAuthAge
)
- Doesn't work with federation
Authorization

Policies
- Description
-
- JSON document that fully defines a set of permissions to access/manipulate AWS resources
- 1 policy contains 1+ permissions
- Provenance
-
- AWS Managed Policies: Applied across multiple accounts
- Customer Managed Policies: Tied to a single AWS account
- Inline Policies: Directly attached to user
Types
|
|
Resource based policies |
- Specifies a
Principal - Can't be managed policies (always inline)
- Not actually IAM policies at all (just use the same policy language)
- Examples: Organizations (SCP), S3, API Gateway, Lambda, KMS, SNS, SQS, SES
|
Identity based policies (IAM policies) |
- Attached to a user/group/role (implicit
Principal ) - Limit of 10 managed policies can be attached
|
Format
Component |
Description |
EFFECT |
Allow /Deny |
SERVICE |
for which the permission apply |
RESOURCE |
- specific ARN for which the permission apply
ARN:AWS:SERVICE:REGION:ACCOUNT-ID:[RECSOURCE-TYPE:]RESOURCE
|
ACTION |
subset of actions within a service that the permission allows/denies |
CONDITION |
optional additional restrictions that limit the actions allowed (e.g., specify IP range/time interval) |
Features
|
|
Permissions boundaries |
- Set the maximum permissions that an identity-based policy can grant to an IAM entity
- Unlike SCPs, can specify resources and use conditions
|
Service Control Policies (SCPs) |
See Organizations |
Session policies |
Like a permission boundary, optionally passed programmatically as part of AssumeRole |
Conditions
|
|
Operators |
Operators are in AND , multiple values in an operator are in OR |
Sources |
- time, MFA, secure transport, user agent
aws:source{Vpc,Vpce (endpoint),Account,Arn,Ip}
|
Principals |
aws:PrincipalOrgID (instead of listing lots of accounts, just use the Org)aws:PrincipalTag/ aws:PrincipalType aws:userid , aws:username
|
NotAction |
Matches everything except the list of actions |
(Not)Principal |
- AWS - users, roles, accounts
- Federated (no info on the role)
- Service (in trust policies)
AWS:* (IAM identities, not services)
|
Policy Association (authz)
- Description
-
- Handled in IAM by defining specific privileges in POLICIES & associating those policies with principals
- Associating Policies with Principals
-
- Associate POLICY - IAM USER
|
|
USER Policy |
exists only in the contest of the user |
MANAGED Policy |
exists independently of users & can be associated with many users/groups |
GROUPS |
simplify managing permissions for large number of users (teams) |
- Associate POLICY - IAM GROUP
|
|
GROUP Policy |
exists only in the contest of the group |
MANAGED Policy |
can also be associated with IAM groups |

- ASSUMING A ROLE
- Actor can be
- Authenticated with IAM User (person/process)
- Person/process authenticated by trusted external service (AWS service will assume the role on the actor's behalf & return a token to the actor)
- After an actor has assumed a role, it is provided with a temporary security token associated with policies of that role
- Policy Resolution
-
- Request
DENIED
by default
- Evaluate policies: if explicit
DENY
found → DENY
- If NO explicit
DENY
& explicit ALLOW
→ ALLOW
- If NO explicit
ALLOW/DENY
→ default DENY
- EXCEPTION = if an
AssumeRole
call includes a role and a policy, the policy cannot expand the privileges of the role (cannot override any permission denied by default in the role)
Federation
- Description
-
- IAM Identity Providers (IDP) = provide ability to federate outside entities with IAM & assign privileges to those users
- IAM can integrate 2 types of outside IDP
|
|
WEB IDENTITIES |
|
INTERNAL IDENTITIES |
- SAML (for AD, LDAP)
- ADFS (AD Federation Services) used to federate internal directory to IAM
|
- Functioning
-
- Works by returning a temporary token associated with a role to the IDP
- Actual Role returned is determined via information received from IDP
- Attributes of the user in the on-premises IDstore
- Username & auth service of WEB IDstore
Security Token Service (STS)
- Description
-
- Grants users limited and temporary access to AWS resources
- Can't be revoked, but you can revoke an IAM user if they created the temporary creds, which invalidates them
Users can come from 3 resources
|
|
Federation (Active Directory) |
- Uses SAML
- Grants temporary access based on the users AD creds
- Does not need to be a user in IAM
|
Federation with mobile apps |
Uses facebook/amazon/google/openid providers to login |
Cross account access |
Let users from one AWS account access resources in another |
Web identity federation
- Description
-
- Lets you give your users access to AWS resources after they have authn with a web-based id provider (amazon, facebook, google)
- Following authn, the user receives an authn code from the web id provider, which they can trade for temporary AWS security credentials
Cognito
|
|
Description |
- Provides Web Identity Federation
- Provides temporary limited-privileged creds for both/unauth users
- Acts as an ID broker between app and web ID provider
- Recommended for all mobile apps AWS services
|
Functioning |
- After user is auth with provider, an OAUTH/OpenID token returned from the provider is passed by your app to Cognito, which returns a new Cognito ID for the user & a set of temp, limited-priv AWS creds
- You will be asked to create a new IAM role for end users
- Has impact on which AWS services they will be able to access
- By default access to: Cognito sync, mobile analytics
|
Identity Pools |
- Store of user identity info that is specific to your AWS account
- Mapping between federated user IDs and Cognito user IDs
- Enable you to create unique identities for your users and authn them with ID providers
- Assign IAM roles to user already authn with another IdP
- Grants temporary AWS creds (either directly from federation, or in exchange for a user pool token)
|
User Pools |
- User directories used to manage sign-up and sign-in functionality for mobile/web apps
- Process
- Users can sign-in directly to the User Pool, or indirectly via an id provider
- Cognito acts as an ID broker
- Successful authn generates JWTs
 |
Organizations
- Description
-
- Account management service which allows to consolidate multiple AWS accounts into an Organization that can be centrally managed
- Features
- Centralized, consolidated billing
- Organize your accounts into groups/OUs for access control
- Attach policy based controls (Service Control Policies)
- Service Control Policy
-
- Used to centrally control the use of AWS services across multiple accounts
- Can be used to create a Permission Boundary
- Restricting the actions the users/groups/roles in those accounts can do (including root)
- Features
- The SCP applies to all OUs and accounts below the OU to which it is attached
- SCPs can deny access only, they cannot allow