Beginning right now, you possibly can cross consumer attributes within the AWS session when your workforce sign-in into the cloud utilizing AWS Single Sign-On. This provides you the centralized account entry administration of AWS Single Signal-On and ABAC, with the flexibleness to make use of AWS SSO, Lively Listing, or an exterior identification supplier as your identification supply. To be taught extra about some great benefits of ABAC insurance policies on AWS, you may read my previous blog post on the subject.

Overview
On one facet, system directors configure consumer attributes on the AWS Single Sign-On identification repository, or the managed Active Directory. System directors may configure an exterior identification supplier, comparable to Okta, OneLogin or Ping Identity to cross current consumer attributes within the AWS classes when their workforce federates into AWS. These attributes are often called session tags in AWS. On the opposite facet, cloud directors create fine-grained permissions insurance policies such that your workforce get solely entry to cloud assets with matching useful resource tags.

Creating insurance policies primarily based on matching attributes as a substitute of purposeful roles helps to cut back the variety of distinct permissions and roles it’s essential to create and handle in your AWS surroundings. For instance, when builders Bob from group pink and Alice from group blue sign-in into AWS and assume the identical AWS Identity and Access Management (IAM) position, they get distinct permissions to venture assets tagged for his or her group. The identification system sends the group title attribute within the AWS session when Bob and Alice sign-in into AWS. The position’s permissions grant entry to venture assets with matching group title tags. Now, if Bob strikes to group blue and system directors replace his group title of their identification supplier listing, Bob robotically will get entry to group blue’s venture assets with out requiring permissions updates in IAM.

The way to Configure AWS SSO to Map Consumer Attributes
Earlier than to configure AWS SSO, there are two necessary factors to focus on. First, ABAC will work with attributes from any identification supply configured in AWS SSO : AWS SSO itself, a managed Active Directory, or an exterior identification supplier. Second, there are two methods to cross attributes for entry management to AWS SSO. Both you possibly can cross attributes straight within the SAML assertion utilizing the prefix https://aws.amazon.com/SAML/Attributes/AccessControl, or you should use attributes which might be within the AWS SSO identification retailer. These attributes are configured by your AWS SSO administrator for customers created in AWS SSO, synchronized in from an Active Directory, or synchronized in from an exterior identification supplier utilizing automatic provisioning (SCIM).

For this demo, I select to make use of an exterior identification supplier and SCIM.

I can allow ABAC in AWS utilizing AWS SSO with three steps:

Step 1: I configure my identification supply with the related consumer identities and attributes within the exterior identification supplier. As of right now, AWS SSO helps identification synchronization by way of SCIM with Azure AD, Okta, OneLogin, and Ping Identity. Examine this page to get an up-to-date checklist. The specifics rely upon every identification supplier.

Step 2: I configure the SCIM attributes I need to use for entry management utilizing the brand new Entry Management Attributes international setting within the AWS SSO console or API. This display screen permits me to pick out attributes for entry management from the identification supply I configured in step 1.

Attributes for Access Control

Step 3: I creator ABAC guidelines by way of permission units and resource-based insurance policies utilizing the attributes I configured in Step 2. Extra about this in a minute.

Now, when my workforce federates into an AWS account utilizing SSO, they get entry to their AWS assets primarily based on matching attributes.

Attributes are handed as session tags. They’re handed as comma-separated key:worth pairs. The entire character size of all of the attributes collectively should be lower than or equal to 460 characters.

What Does a Coverage Look Like?
I now can use consumer attributes in my permission units utilizing the aws:PrincipalTag situation key when creating entry management guidelines. For instance, I can tag all of the assets in my group with their respective division title, and use a single permission set that grants builders entry solely to their division assets. Now, each time builders federate into the AWS account, AWS SSO creates a division session tag with the worth obtained from the identification supplier. The safety insurance policies enable them to solely get entry to the assets of their respective division. Because the group provides extra builders and assets to their venture, I solely should tag assets with the proper division title. Consequently, because the group provides new assets and builders to departments, builders can solely handle assets aligned to their division while not having any permission updates.

An ABAC SSO permission set coverage would possibly appear to be this:

{
    "Model": "2012-10-17",
    "Assertion": [
        
            "Effect": "Allow",
            "Action": [ "ec2:DescribeInstances"],
            "Useful resource": "*"
        ,
        
            "Impact": "Permit",
            "Motion": ["ec2:StartInstances","ec2:StopInstances"],
            "Useful resource": "*",
            "Situation": 
                "StringEquals": 
                    "ec2:ResourceTag/Division": "$aws:PrincipalTag/Division"
                
            
        
    ]
}

This coverage permits anyone to DescribeInstances, however solely customers with a aws:PrincipalTag/Division tag’s worth matching the EC2 occasion ec2:ResourceTag/Division tag’s worth are approved to cease or to start out cases.

I connect this coverage to an AWS Account’s Permission Set. On the left a part of the AWS Single Signal-On console, I click on AWS Accounts and choose the Permission units tab. Then I click on Create permission set. On the following display screen, I choose Create a buyer permission set.

Create a custom permission set

I enter a reputation and outline, I ensure that Create a customized permissions coverage is chosen. Then I can copy/paste the earlier coverage permitting to start out and cease EC2 cases when the division title tag worth is the same as the individual’s division title tag worth.

Create Custom Policy for Permission Set

On the following display screen, I enter some tags, then I assessment my configuration earlier than clicking Create. Et voila, I’m able to go.

When you’ve got current federation configured with AWS Security Token Service, do not forget that exterior identification suppliers think about AWS SSO as a brand new software configuration. This implies once you transfer from direct IAM federation to AWS SSO, you must replace your exterior identification supplier configuration to attach with AWS SSO and to introduce attributes as session tags for this configuration.

Accessible Right now
There isn’t a further cost to configure consumer attributes with AWS Single Sign-On. You’ll be able to start to use it right now in all AWS Areas the place AWS SSO is out there.

— seb





Leave a Reply

Your email address will not be published. Required fields are marked *