Identity federation with multiple AWS accounts
--
How should we design user access to multiple AWS accounts? As organizations scale, they tend to centralize identity with SSO SAML federation, but there are two patterns for federation with AWS.
Hub-and-spoke: users assume federated roles into a single AWS “identity account” and perform a second role assumption into sub-accounts
Direct: users assume federated roles into AWS sub-accounts directly
Let’s look at examples of each and tradeoffs between the two.
Hub-and-spoke AWS IAM federation
AWS Multiple Account Security Strategy from AWS Answers describes a hub-and-spoke model where IAM Groups of IAM users can assume roles from a central identity account.
If you use IAM users instead of federation, an identity account has obvious advantages for onboarding and offboarding users, establishing MFA, etc.
For cross-account IAM roles in federated use cases, AWS Answers points to the now-archived cross-account-manager. This tool builds a federated “hub-and-spoke” model with per-account roles that can be assumed from the identity account.
There are real-world federated hub-and-spoke AWS IAM multi-account setups. Segment’s Secure access to 100 AWS accounts article describes per-team “hub” identity accounts with sub-accounts. The aws-iam-generator project from AWS Labs implements hub-and-spoke, although there’s an open issue to support direct federation. A Reddit commenter described the benefits of automating changes with a single AWS account in a hub-and-spoke model:
We have security groups in AD that are linked to roles that are managed via SSO across accounts… It’s so much easier to manage them across accounts this way vs traditional SSO with a cross account IAM role per account (have to change that role on all 30+ accounts).
CloudConformity even has a “high” risk finding for not using AWS Multi-Account Centralized Management, which looks like hub-and-spoke.
