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 programatically as part of AssumeRole |
Conditions
| |
Operators | Operators are ANDed, multiple values in an operator are ORed |
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