Identity and access management

Key points

• Users: long-term credentials (a password and up to 2 access keys). Use them only when a role cannot work, such as some third-party tools.
• Groups: attach policies to many users at once. A user can belong to up to 10 groups, and groups cannot contain other groups.
• Roles: no long-term credentials. Assumed by users, AWS services (EC2 instance profile, Lambda execution role) or federated identities to get temporary credentials.
• Policies: identity-based policies (managed or inline) attach to principals. Resource-based policies (bucket policy, queue policy, KMS key policy) name a Principal and enable cross-account access.
• Least privilege: start from AWS managed policies, then narrow with customer managed policies, conditions and IAM Access Analyzer policy generation from CloudTrail activity.

Key points

• Explicit deny: a Deny in any applicable policy overrides every Allow.
• Same account: permissions are the union of identity-based and resource-based policies, so an allow in either one is enough.
• Cross-account: the principal needs an Allow in its identity policy and an Allow in the resource-based policy of the other account.
• Permissions boundary: a managed policy that sets the maximum permissions of a user or role. Effective permissions are the intersection with the identity policies, and the boundary grants nothing by itself.
• Guardrails: SCPs, RCPs and session policies only limit. An action must be allowed by every one of them that applies.

Key points

• AssumeRole: sessions last from 15 minutes up to the maximum session duration of the role, which you set between 1 and 12 hours. The default is 1 hour.
• Role chaining: using one role to assume another limits the session to 1 hour.
• Trust policy: the resource-based policy of the role that says who can assume it with sts:AssumeRole. The permissions policy says what the session can do.
• Role vs resource policy: a principal that switches to a role gives up its original permissions. Access through a resource-based policy keeps them, which helps when copying data between accounts.
• External ID: a condition in the trust policy when a third party assumes a role in your account. Its purpose is to prevent the confused deputy problem.
• Federation APIs: AssumeRoleWithSAML for SAML 2.0 IdPs and AssumeRoleWithWebIdentity for OIDC tokens.

Key points

• MFA: AWS enforces MFA for the root user by default. Phishing-resistant MFA, such as passkeys and security keys, is recommended.
• Daily work: use an administrative user in IAM Identity Center, never the root user. Delete root access keys you do not need.
• Root-only tasks: close a standalone account, restore IAM permissions when the only administrator locked itself out, register as a seller in the Reserved Instance Marketplace, enable MFA delete on an S3 bucket.
• Centralized root access: in AWS Organizations you can remove root credentials from member accounts and run privileged tasks from the management account, such as unlocking a bucket policy that denies everyone.
• SCPs apply: an SCP restricts the root user of a member account, but never the management account.

Key points

• Identity source: the Identity Center directory, Active Directory (AWS Managed Microsoft AD or AD Connector) or an external IdP over SAML 2.0.
• Permission sets: define the permissions of a job function once, then provision them in many accounts and assign them to users and groups.
• Organization instance: deployed in the management account, it is the only instance type that manages access to AWS accounts. Account instances serve isolated application deployments.
• AWS access portal: one sign-in page that lists every account and application assigned to the user, with short-term credentials for the console and CLI.
• Trusted identity propagation: AWS managed applications such as Amazon Quick pass the user identity to services like Amazon Redshift for authorization and auditing.

Key points

• SAML 2.0: a corporate IdP such as Active Directory Federation Services authenticates the user, and STS AssumeRoleWithSAML returns credentials for an IAM role.
• Directory groups to roles: the IdP assertion maps users or groups of the directory to IAM roles, so access follows group membership.
• OIDC: tokens from providers such as GitHub Actions are exchanged through AssumeRoleWithWebIdentity, so pipelines run without stored keys.
• IAM or Identity Center: federation directly in IAM fits a single standalone account or machine users. For many accounts, federate once into IAM Identity Center.
• IAM Roles Anywhere: workloads outside AWS get temporary credentials with an X.509 certificate from your PKI.

Key points

• User pools: a user directory and OIDC provider that issues JWTs (ID and access tokens). Supports sign-up, MFA, social sign-in and enterprise SAML or OIDC IdPs.
• Identity pools: exchange a trusted token for temporary, limited-privilege AWS credentials from STS. They can also give guests unauthenticated access.
• Together: sign in with a user pool, then trade the user pool token at an identity pool for credentials to call S3 or DynamoDB directly.
• API protection: API Gateway can validate user pool tokens before invoking the backend, and AWS WAF can protect the user pool.
• Access control: identity pools pick an IAM role per user (role-based) or map claims to session tags (attribute-based).

Key points

• AWS Managed Microsoft AD: a real Windows Server AD run by AWS. Supports trusts with on-premises AD, MFA, schema extensions and Amazon RDS for SQL Server.
• Editions: Standard targets up to about 30,000 directory objects, Enterprise up to about 500,000.
• AD Connector: a proxy that forwards sign-in requests to your on-premises domain controllers, with no directory synchronization. It can use your RADIUS MFA.
• Simple AD: a low-cost AD-compatible directory powered by Samba 4. No trusts, no MFA and no RDS for SQL Server.