Multi Account Access and Federation

What it is

With dozens of accounts you cannot create an IAM user in each one. The scalable pattern is one identity source, central assignment of access, and short lived role sessions in every account.

Humans usually sign in through AWS IAM Identity Center. Applications and pipelines assume roles, either across accounts or through federation from an external identity provider.

How it works

IAM Identity Center

IAM Identity Center is the recommended way to give workforce users access to multiple accounts and applications. It works with AWS Organizations, and you can enable it in the management account and delegate administration to another account.

With an external provider, users and groups are synchronized with SCIM, and sign in uses SAML 2.0. Sessions are temporary, so there are no long lived keys on laptops.

aws configure sso
aws sso login --profile dev-admin
aws s3 ls --profile dev-admin

Changing a permission set updates the roles in every assigned account, which is the key scale advantage. Attributes from the identity source can drive attribute based access control.

Cross account roles

For automation, the standard pattern is a role in the target account that trusts the source account. The pipeline or tool assumes it with STS.

Check three things: the trust policy in the target role, the permissions policy of the target role, and the permission of the source principal to call sts:AssumeRole. Avoid reusing OrganizationAccountAccessRole for automation, and create purpose built roles with narrower permissions.

A resource policy with aws:PrincipalOrgID lets any account in the organization read a bucket without listing accounts one by one.

Federation

Federation lets an external identity provider vouch for a user, so no IAM user is needed.

Pipelines outside AWS can use OIDC federation rather than stored access keys. For example, a Git hosting service issues a signed token per workflow run, and an IAM role trusts it.

{
  "Effect": "Allow",
  "Principal": {"Federated": "arn:aws:iam::111122223333:oidc-provider/token.actions.githubusercontent.com"},
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"},
    "StringLike": {"token.actions.githubusercontent.com:sub": "repo:my-org/my-repo:*"}
  }
}

The condition on the subject claim limits which repository can assume the role. Without it, any repository using that provider could.

Sharing resources without copying

AWS Resource Access Manager (RAM) shares resources across accounts or with an organization, such as VPC subnets, Transit Gateways, Route 53 Resolver rules, License Manager configurations and more. The owner account keeps control, and participants use the shared resource as if it were local. Shared subnets let many accounts place workloads in a central network.

Guardrails around all of this

• SCPs cap what any role can do in the member accounts.
• Permission boundaries limit roles that teams create themselves.
• Delegated administrators move management of services such as Identity Center, GuardDuty and Security Hub out of the management account.
• Break glass access is a documented, monitored, MFA protected path for emergencies, with alarms when it is used.

Machine identities

Prefer roles for every machine identity: instance profiles, task roles, execution roles and IRSA (IAM roles for service accounts) on Kubernetes. If you must store a secret credential, keep it in Secrets Manager with rotation.