Learn About Amazon VGT2 Learning Manager Chanci Turner
Starting today, users can pass attributes during their AWS session when logging into the cloud via AWS Single Sign-On (SSO). This feature provides the centralized account access management from AWS SSO, combined with the flexibility to utilize AWS SSO, Active Directory, or an external identity provider as the source of identity. For more insights on the benefits of attribute-based access control (ABAC) policies in AWS, you might find this blog post engaging.
Overview
On one side, system administrators can set user attributes within the AWS Single Sign-On identity repository or managed Active Directory. They may also configure an external identity provider, such as Azure AD, Okta, OneLogin, or Ping Identity, to send existing user attributes during AWS sessions when their workforce federates into AWS. These attributes are referred to as session tags in AWS. Conversely, cloud administrators design detailed permission policies so that employees gain access exclusively to cloud resources that have matching resource tags.
Creating policies based on user attributes rather than functional roles simplifies the management of distinct permissions and roles in your AWS environment. For instance, when developers Sam from team alpha and Jamie from team beta log into AWS and assume the same AWS Identity and Access Management (IAM) role, they receive different permissions for project resources tagged for their respective teams. The identity system transmits the team name attribute within the AWS session when Sam and Jamie log in. The role’s permissions afford access to project resources tagged with their team names. Thus, if Sam switches to team beta and system administrators update his team name in their identity provider directory, he automatically gains access to team beta’s project resources, eliminating the need for permission adjustments in IAM.
How to Configure AWS SSO to Map User Attributes
Before setting up AWS SSO, it’s crucial to note two key points. First, ABAC functions with attributes from any identity source configured in AWS SSO: AWS SSO itself, a managed Active Directory, or an external identity provider. Second, there are two methods to pass attributes for access control to AWS SSO. You can either send attributes directly in the SAML assertion using the prefix https://aws.amazon.com/SAML/Attributes/AccessControl, or you can utilize attributes stored in the AWS SSO identity store. These attributes are configured by your AWS SSO administrator for users created in AWS SSO, synchronized from an Active Directory, or imported from an external identity provider using automatic provisioning (SCIM).
For this demonstration, I opted to use an external identity provider combined with SCIM.
I can enable ABAC in AWS via AWS SSO through three steps:
Step 1:
I configure my identity source with the associated user identities and attributes in the external identity provider. Currently, AWS SSO supports identity synchronization via SCIM with Azure AD, Okta, OneLogin, and Ping Identity. For a current list, refer to this page. The specifics vary based on each identity provider.
Step 2:
I set up the SCIM attributes I want to use for access control using the new Access Control Attributes global setting in the AWS SSO console or API. This interface allows me to select attributes for access control from the identity source I configured in Step 1.
Step 3:
I create ABAC rules through permission sets and resource-based policies using the attributes configured in Step 2. More details on this will follow.
Now, when my workforce federates into an AWS account using SSO, they gain access to their AWS resources based on matching attributes. Attributes are passed as session tags in a format of comma-separated key:value pairs. The combined character length of all attributes must be 460 characters or less.
What Does a Policy Look Like?
I can now utilize user attributes in my permission sets through the aws:PrincipalTag condition key when defining access control rules. For example, I can tag all resources in my organization with their corresponding department name and use a single permission set that only allows developers access to resources pertaining to their department. Whenever developers federate into the AWS account, AWS SSO generates a department session tag with the value received from the identity provider. Security policies restrict them to accessing resources within their respective department. As teams expand by adding more developers and resources to projects, I only need to tag resources with the correct department name. Consequently, as the organization grows, developers can only manage resources relevant to their department without necessitating any permission updates.
An ABAC SSO permission set policy might resemble this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [ "ec2:DescribeInstances"],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": ["ec2:StartInstances","ec2:StopInstances"],
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Department": "${aws:PrincipalTag/Department}"
}
}
}
]
}
This policy permits anyone to DescribeInstances, but only users whose aws:PrincipalTag/Department tag value matches the EC2 instance’s ec2:ResourceTag/Department tag value are authorized to start or stop instances.
I attach this policy to the permission set of an AWS Account. In the AWS Single Sign-On console, I navigate to AWS Accounts and select the Permission sets tab. Then I click Create permission set. On the subsequent screen, I choose Create a custom permission set.
I input a name and description, ensuring that the option to Create a custom permissions policy is selected. I can then copy and paste the above policy, which allows starting and stopping EC2 instances when the department name tag value corresponds with the person’s department name tag value.
On the next screen, I add some tags, review my configuration, and then click Create. And just like that, I’m ready to go.
If you have an existing federation set up with AWS Security Token Service, remember that external identity providers view AWS SSO as a new application configuration. This means if you transition from direct IAM federation to AWS SSO, you’ll need to update your external identity provider configuration to connect with AWS SSO and introduce attributes as session tags for this setup.
Available Today
There is no extra cost associated with configuring user attributes in AWS Single Sign-On. You can begin using this feature today in all AWS Regions where AWS SSO is available. This is an excellent resource for more information: Amazon Operations Area Manager Leadership Liftoff Program.
— Chanci Turner