Centralized access management for Terraform
This is an overview of our approach to centralized access management and the relationships between the components used to implement it. It explains how SAML, SSO, and custom constructs for AWS teams and team roles interact to provide efficient role delegation and authentication across an AWS Organization.
AWS Teams and Team Roles
Why do we need Teams and Team Roles when we have the same thing in Identity Center? To explain that, let’s first explain what they do and how we’ve integrated them.
AWS Teams
The aws-teams component creates AWS Teams in the Identity account. The Team is the entry point for a group of
users, and the Identity account acts as an "Identity Hub" for centralized role assumption management across all
delegated accounts.
Think of each team as a group of users, such as developers or devops.
AWS Team Roles
The aws-team-roles component defines common IAM Roles in all accounts, as well as defines the AWS Team(s) able to
assume the role in any account.
These roles should be identical in all accounts, such that you can always expect admin to be admin, poweruser to
be poweruser, and observer to be observer. The only difference between accounts is which AWS Team is able to
assume the role. We also have a terraform role that is used by Terraform to apply changes across all accounts.
Example
Consider this example. We want to enable the “DevOps” to assume Administrator in multiple accounts, such as dev or prod. However, “developers” can only assume admin in dev. Here’s how that would work:
In the core-identity account, we have a developers team and a devops team. Then in the plat-dev account, we have an admin team role. And in the plat-staging account we have an admin and an observer team role. With our design, the developers team can assume admin only in plat-dev, but the devops team can assume admin in both plat-dev and plat-staging.
Using AWS Identity Center for Single Sign On
Now how does AWS IAM Identity Center fit in? Let’s see how we can connect AWS Teams and Team roles with Identity Center to complete the picture.
Connecting a Permission Set to an AWS Team
Identity Center has the concept of Permission Sets. Permission Sets determine what a user can or cannot do. We simply connect those Permission Sets to one of our Teams.
We define a special Permission Set for the core-identity account, called the Identity{X}TeamAccess Permission Set. This Permission Set has access to assume the related AWS Team. For example, the IdentityDeveloperTeamAccess permission set can assume the developers team and the IdentityDevopsTeamAccess permission set can assume the devops team.
From their AWS Team, users can apply Terraform wherever they have access
Centrally Manage Users and Groups with an IdP
We still need some method to manage users and groups. AWS Teams and Team roles grant groups of users access, but do not define or manage users. AWS IAM Identity Center ties together Teams and Team roles with a predefined set of users and groups.
Although you may choose to manage users and groups directly in Identity Center, the vast majority of our customers choose to use a SAML IdP as the source of truth for their users and groups. With a SAML IdP, users and groups are not created in AWS. Instead, we connect a third-party Identity Provider, such as GSuite, JumpCloud or Okta. Then we manage all Users and Groups in that IdP
With “automatic provisioning” in AWS, we can synchronize all users and groups from the IdP into AWS. Then we can create Permission Sets in AWS to assign to those groups. We can assign Permission Sets to Groups for any given account. A Permission Set, such as AdministratorAccess or ReadOnlyAccess, is granted to a given group for some account. This way, we only need to define the Permission Sets once each
Access the AWS Web Console with Identity Center
With Identity Center, it’s very easy to log into the AWS web console. Simply open the Single Sign On Portal link, and select the account and role you want to access.
For example, if I wanted to connect to plat-prod with “Read Only” access, then I would select the ReadOnlyAccess Permission Set for plat-prod. AWS then will launch a new session with the appropriate permissions in production
Deploying both AWS IAM Identity Center and AWS SAML
AWS IAM Identity Center and AWS SAML are not mutually exclusive solutions. They can be used together to provide a seamless login experience for users. Cloud Posse frequently deploys both in customer environments - AWS SAML to log in ourselves for the duration of the engagement and AWS IAM Identity Center for the customer to use and support. That way the customer can access AWS via their chosen Identity Provider (IdP), and we can use GSuite SAML to access the Identity account team directly. When an engagement is complete, we can easily decommission our access by removing the SAML connection.
The vast majority of our customers prefer AWS IAM Identity Center (SSO). The convenience of a web console login is hard to beat. However, some customers prefer SAML for its simplicity and compatibility with existing systems. We support both methods, and you can choose the one that best fits your needs.
FAQ
Why use AWS SAML?
SAML offers granular control over identity management with your IdP in AWS. With our aws-saml component, you can integrate multiple IdPs, and we explicitly provision every role, policy, and trust relationship needed. The aws-saml component allows users to assume any number of roles to access AWS accounts that are associated with their IdP groups.
This component creates an Identity Provider (IdP) in the Identity account to allow federated access to an identity role. Follow the Identity Providers documentation for adding a SAML login.
With AWS SAML, we create a federated SAML login that connects to the "team" in the identity account, and then users can assume other roles from there. We use the AWS Extend Switch Roles plugin that makes this much easier, but it's not as intuitive as Identity Center.
A federated login means that instead of managing separate credentials for each AWS account, users authenticate through a centralized identity provider (IdP). This allows them to access multiple AWS accounts or services using a single set of credentials, based on trust relationships established between the IdP and AWS.
How do I use AWS IAM Identity Center (SSO)?
AWS IAM Identity Center (SSO) is natively integrated with the AWS Web Console and the AWS CLI. You don't need to do anything special to get started with it once it's been properly configured.
Specifically, the aws-sso component connects AWS IAM Identity Center (Successor to AWS Single Sign-On) Groups to Permission Sets.
Permission Sets grant access to aws-teams in the Identity account or (optional) access to an individual account for
convenience.
Permission Sets other than the Identity Team Access Permission Set are used only for console and CLI access to a single account. These are redundant with AWS Team Roles but are useful for quickly accessing a given account with limited permission.
With AWS IAM Identity Center, you can directly access a specific account from the single sign-on page, which will automatically assume the role with the associated PermissionSet. This is great for web console usage but not ideal for locally applying Terraform. With Terraform, we need to apply changes across many accounts, where each account has its own role. We don't want to assume a new role each time we change accounts. To solve this, we have a specific Permission Set that can assume an AWS team role in the identity account. When applying Terraform, we assume that "team" role via SSO, and when accessing the web console, we use the Permission Set directly.