Kelvin’s Engineering Wiki

AWS IAM

4 min read

AWS Identity and Access Management (IAM) decides who can sign in to AWS and what each identity may do. This page covers the building blocks (users, groups, roles, and policies), how IAM evaluates the policies on a request, and IAM Identity Center for giving a workforce single sign-on across accounts.

What IAM is

AWS Identity and Access Management (IAM) controls authentication (who is signed in) and authorization (what they may do) for AWS resources. IAM, IAM Identity Center, and AWS STS carry no additional charge, and IAM is eventually consistent.1 How a request is decided is covered under IAM policy evaluation.

Building blocks

PieceRole
Root userThe initial full-access identity; not for everyday work
Users, groups, rolesIdentities for people and workloads; roles give temporary credentials
PoliciesJSON documents on identities or resources defining permissions
AWS STSIssues temporary credentials, for example AssumeRole
Permissions boundariesCap what identity-based policies can grant
Organization SCPs and RCPsCross-account boundaries that grant nothing by themselves

As defined in the note.1

Practices

  • Temporary credentials everywhere: federated sign-in through IAM Identity Center for people, roles for workloads (instance profiles, Lambda execution roles, ECS/EKS task roles).
  • MFA for the root user and any long-term credentials; never use root routinely.
  • Least privilege, starting from AWS managed policies; IAM Access Analyzer can generate least-privilege policies from CloudTrail activity and detect public or cross-account access.
  • Remove unused users, roles, policies, and keys using last-accessed information.1

Troubleshooting

SymptomCheck
AccessDeniedIdentity policy, resource policy, SCP/RCP, boundary, session policy; retry after propagation
AssumeRole failsThe trust policy allows the principal, external ID, session duration within the role maximum (up to 12 hours)
Cannot delete a user or roleRemove policies, keys, and memberships first

As tabled in the note.1

Default quotas

1,000 roles, 1,500 customer managed policies, 300 groups, 20 managed policies per role and 10 per user, a managed policy size of 6,144 characters, a maximum session of 12 hours, and 600 STS requests per second per account per Region.1

IAM policy evaluation

AWS evaluates every request against several independent policy layers. An explicit deny in any layer wins, and a request is denied unless an applicable layer explicitly allows it.1

flowchart TD
    accTitle: IAM authorization decision
    accDescr: A request is checked against identity-based policies, resource-based policies, organization SCPs and RCPs, and any permissions boundary. An explicit deny in any layer denies it; otherwise it needs an explicit allow from the applicable layers.
    R[Request] --> L[Identity policy, resource policy, SCP/RCP, permissions boundary]
    L --> D{Explicit deny anywhere?}
    D -- Yes --> X[Denied]
    D -- No --> A{Explicit allow?}
    A -- Yes --> OK[Allowed]
    A -- No --> X

Layers that only narrow

Two layers can only take permissions away. A permissions boundary caps what identity-based policies can grant. Organization SCPs and RCPs set cross-account boundaries and grant nothing by themselves; SCPs also do not apply to the management account, which is why an SCP can appear to have no effect.12

Debugging AccessDenied

Check each layer in turn: identity policy, resource policy, SCP or RCP, permissions boundary, and session policy. IAM is eventually consistent, so a just-made change may need time to propagate.1

The same layered model applies to agent tooling; see Least-privilege tool access.

AWS IAM Identity Center

IAM Identity Center (the successor to AWS Single Sign-On, renamed in July 2022) centrally manages workforce identities and their access to AWS accounts and cloud applications. It is AWS’s recommended service for multi-account access.3

How access is granted

Users and groups come from the Identity Center directory or an external IdP (such as Okta or Microsoft Entra ID, via SCIM provisioning and SAML 2.0). An account assignment gives a user or group a permission set (a named collection of IAM policies plus a session duration) in an account, and people sign in through the access portal with MFA. The APIs keep the old sso, sso-admin, and identitystore namespaces; CLI login is aws sso login.3

Practices

  • Create the instance in the organization’s management account and assign access to groups, not individuals.
  • Use an external IdP as the source of truth with SCIM provisioning; require MFA.
  • Keep permission sets least-privilege with a suitable session duration, and review assignments with CloudTrail.3

Troubleshooting

SymptomCheck
No access to an accountAssignment, group membership, permission set, instance in the management account
External IdP users missingSCIM enabled, bearer token valid, SAML metadata current
CLI login errorRe-run aws configure sso; session name and start URL match
New account invisibleAccount is in the organization; re-run assignments

As tabled in the note.3 See also Multi-account governance.

Footnotes

  1. AWS IAM - Runbook & Reference, original ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  2. AWS Organizations - Runbook & Reference, original ↩

  3. AWS IAM Identity Center - Runbook & Reference, original ↩ ↩2 ↩3 ↩4

Backlinks