aws-teams/roles vs. aws-identity-center

[j4zzcat]

Hello,

I'm building our authorization model on the aws-identity-center component with groups and permission sets.
I'm evaluating whether the aws-teams and aws-team-roles components still serve a unique purpose, or perhaps they can be fully replaced by the IdC/PS model to simplify the identity architecture?

[milldr]

That’s a great question, and it’s something we’re evaluating ourselves right now.

We use AWS Identity Center to grant access to permission sets, but the aws-teams and aws-team-roles components still serve two key purposes in the current architecture.

1. Delegated role assumption: They allow automation systems like Terraform to assume a delegated role (for example, the terraform or planner roles) in every account from a centralized IAM “team” role in the identity account. That delegated role is determined with account-map
2. Terraform state access: They provide a static IAM role that can be granted access to the Terraform state backend, typically hosted in the root account. This enables consistent and predictable access for automation without relying on human IdC sessions.

However with the recent release of Atmos Auth, this dynamic role assumption can now be handled directly within Atmos! Instead of chaining through aws-teams roles, you can remove the dynamic account map IAM role logic from providers.tf and define the authentication configuration in your Atmos stacks. That means you can specify a Permission Set to apply Terraform directly.

Yet one remaining consideration is Terraform state access. Most permission sets don’t include access to the centralized backend by default, so this would need to be addressed either by deploying account-specific state or granting additional access to the required permission sets.

Atmos Auth was released last week, but it represents a clear path forward toward simplifying the identity architecture. One of the main goals of implementing Atmos Auth was to eventually deprecate the account-map and the aws-teams and aws-team-roles components. We’re actively evaluating this direction and can share guidance as the architecture evolves.

[petabook]

Atmos Auth looks promising - kudos!

For now, to minimize the footprint of team/role, the approach would be:

• Use IdC/PS to manage human access
• Use team/roles to manage machine access, essentially, just the planner and applier roles for Terraform

This doesn’t completely eliminate team/role usage, but it reduces their scope to the bare minimum necessary.

[milldr]

Following up on this now, since we have completely eliminated aws team/role usage!

Atmos auth doesnt eliminate team/role usage on its own, but it enables us to select a specific identity for each stack. That we can specify a different role or permission set in each, and no longer need to use account-map to assume a Terraform role in the target account during Terraform execution. Atmos now assumes the role before running Terraform. That way we can simply execute Terraform with a predefined Permission Set in each account (or IAM role for machine users)

1. High level explanation of the architecture: https://docs.cloudposse.com/layers/identity/
2. Long explanation of the evolution from our identity model to where we are today: https://docs.cloudposse.com/layers/identity/tutorials/access-control-evolution/

[GabisCampana]

Hi @j4zzcat ,

Following up to see if this discussion is resolved on your end.

If this answers your question, please feel free to close the discussion.

Let us know if there are any remaining gaps or edge cases you’d like to explore.