Home / AWS

AWSChecklistIntermediate

AWS identity foundation: IAM Identity Center, permission sets and break-glass access

Centralise human access with IAM Identity Center, design permission sets per role, remove long-lived keys, protect root users and keep an audited emergency access path.

Deepak Bhardwaj2 min read

Applies toAWS IAM Identity Center, AWS Organizations, IAM

1. Identity source

  • IAM Identity Center enabled in the management account (or delegated admin), in your home region.
  • Connected to your IdP (Entra ID, Okta) with SCIM provisioning of users and groups.
  • MFA enforced at the IdP.

2. Permission sets

Permission set Policies Who
ReadOnly ReadOnlyAccess Support, auditors
OpsL2 ViewOnlyAccess + EC2/SSM operations custom policy Operations
Developer PowerUserAccess with a permissions boundary App teams (non-prod)
Admin AdministratorAccess, session 1 hour Platform team

Assign groups to accounts with permission sets. Shorter session durations for admin sets.

aws sso-admin list-permission-sets --instance-arn arn:aws:sso:::instance/ssoins-1234567890abcdef
aws sso login --profile payments-prod-ops     # engineers use short-lived credentials

3. No long-lived IAM user keys

  • Humans: Identity Center only.
  • Workloads on AWS: IAM roles (EC2 instance profiles, ECS task roles, EKS Pod Identity / IRSA, Lambda execution roles).
  • CI/CD: OIDC federation (GitHub Actions, GitLab) to assume a role.
  • Remaining IAM users with keys inventoried, with rotation and owners.
aws iam generate-credential-report && aws iam get-credential-report --query Content --output text | base64 -d | cut -d, -f1,4,9,10,11 | column -s, -t

4. Root users

  • MFA (hardware key) on every account's root user; no access keys.
  • With AWS Organizations centralised root access management, remove root credentials from member accounts where possible.
  • Alert on root sign-in (EventBridge rule on ConsoleLogin with userIdentity.type = Root).

5. Break-glass

  • An emergency path if the IdP is down: for example a dedicated IAM user (or a local Identity Center user) with MFA in the management account that can assume an admin role, credentials in a safe.
  • Alerts on its use, and quarterly tests.

6. Guardrails on IAM itself

  • SCP denying iam:CreateUser / iam:CreateAccessKey in workload OUs (exceptions by role tag).
  • IAM Access Analyzer for external access and unused access findings.
  • Permissions boundaries when developers can create roles.

DR note

Identity Center is enabled in one home Region. Check the current documentation for multi-Region options, and in any case keep the break-glass path working, so you can still administer accounts (including the DR region) if the Identity Center Region has an outage.

Related fixes