Home / AWS

AWSRunbookIntermediate

Transformation: from IAM users in every account to IAM Identity Center and roles

Replace per-account IAM users and long-lived access keys with IAM Identity Center, federated to your identity provider. Design permission sets, move people account by account, switch the CLI to SSO profiles and delete the old users.

Deepak Bhardwaj3 min read

Applies toAWS IAM Identity Center, AWS Organizations, Microsoft Entra ID / Okta (SAML + SCIM), AWS CLI v2

Why

IAM users mean a password and keys per person per account, manual offboarding and keys that never rotate. Identity Center gives one sign-in, short-lived credentials, and access that disappears when HR disables the account in your IdP.

1. Inventory

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > cred-report.csv

The report shows each user's password and key age and last use. Run it in every account (or use an Organizations-wide script). Split users into humans and workloads — workloads move to roles separately (instance profiles, OIDC, Roles Anywhere).

2. Connect your identity provider

  • Enable Identity Center in the management account (or delegate administration to a security account).
  • Set the identity source to an external IdP (Entra ID, Okta) with SAML 2.0.
  • Turn on SCIM provisioning so users and groups sync automatically.

3. Design permission sets

Map job roles, not individuals:

Permission set Policies Session
ReadOnly ReadOnlyAccess 8h
Developer Custom: app services in dev accounts 8h
PlatformAdmin AdministratorAccess, assigned to few 1–4h
Billing Billing job function 8h
BreakGlass Admin, alerting on use 1h 
aws sso-admin create-permission-set --instance-arn <instance-arn> --name Developer --session-duration PT8H
aws sso-admin attach-managed-policy-to-permission-set --instance-arn <instance-arn> \
  --permission-set-arn <ps-arn> --managed-policy-arn arn:aws:iam::aws:policy/PowerUserAccess
aws sso-admin create-account-assignment --instance-arn <instance-arn> --target-id 111122223333 \
  --target-type AWS_ACCOUNT --permission-set-arn <ps-arn> --principal-type GROUP --principal-id <group-id>

Assign groups, never individual users.

4. Switch the CLI

aws configure sso
# SSO session name: corp
# SSO start URL: https://contoso.awsapps.com/start
# SSO region: eu-west-1
aws sso login --profile dev-developer
aws sts get-caller-identity --profile dev-developer

Update scripts that read ~/.aws/credentials keys to use the SSO profile. SDKs pick up SSO profiles automatically.

5. Migrate account by account

  1. Assign groups and permission sets in the account.
  2. Ask users to sign in through the access portal and confirm they can do their work.
  3. Deactivate their IAM users' keys and console passwords (don't delete yet).
  4. After two weeks without complaints, delete the IAM users.
aws iam update-access-key --user-name alice --access-key-id AKIA... --status Inactive
aws iam delete-login-profile --user-name alice

6. Lock it in

  • SCP that denies iam:CreateUser and iam:CreateAccessKey outside a break-glass role.
  • AWS Config rule for IAM users with console access or old keys.
  • Keep a tested break-glass path (root with MFA in the management account and a documented procedure) for when the IdP is down.

Checklist

  • Credential reports from all accounts; humans vs. workloads split
  • IdP connected with SCIM
  • Permission sets by job role, assigned to groups
  • CLI and scripts on SSO profiles
  • IAM users deactivated, then deleted; SCP in place

Related fixes