Attribute-Based Access Control (ABAC) for AWS

What is attribute-based access control?

Attribute-based access control (ABAC) is an authorization strategy that lets you create fine-grained permissions based on user attributes, such as department, job role, and team name. User attributes make permissions more intuitive, and they simplify the administrative experience of managing access. By specifying permissions using attributes, you can reduce the number of distinct permissions that you need for creating fine-grained controls in your AWS account.

For example, instead of creating AWS Identity and Access Management (IAM) roles with distinct policies for every team or individual to ensure the right levels of access, you can use ABAC to group attributes to identify which resources a set of users can access. Then, as you add new users and resources, you can associate the appropriate attributes so that the right users have access to the right resources. It’s no longer necessary to update existing policies to allow new users to access resources. With attribute-based access controls, your authorization strategy can scale at the pace of your innovation. Learn about the services you can use in your ABAC strategy.


Simplify IAM role management

With ABAC, multiple users using the same IAM role can still get unique, fine-grained access because permissions are based on user attributes. You can define attributes in AWS, or you can pass user attributes from your existing identity provider (IdP) into AWS by using AWS IAM Identity Center (successor to AWS SSO), IAM, or Amazon Cognito. You than can author IAM policies to ensure that your users get access to only the AWS resources that have matching attributes. This approach helps you reduce the number of IAM roles you need for the use cases in your AWS account.

Apply fine-grained permissions as resources change

With ABAC, you grant access based on user attributes. You can use attributes you've assigned in AWS, or you can pass in attributes from your IdP and update user attributes in your IdP. Users with specific attributes can immediately access new resources that have matching attributes, which happens without you having to update users’ permissions.

Monitor actions that users have performed

When using ABAC, you can determine which identity is responsible for actions performed using IAM roles. For example, the IAM SourceIdentity attribute is logged in AWS CloudTrail for every action performed in AWS using an IAM role. With the SourceIdentity attribute set, you can connect the CloudTrail event with the identity of the user or application that performed the action. Even in the case of role chaining, where a user uses one IAM role to assume another IAM role, you can determine which identity performed which actions.

Fundamentals of ABAC for AWS

Access control confidence: Grant the right access to the right things (53:39)

Learn how to use ABAC to set fine-grained permissions that scale with your organization.

ABAC in AWS with AWS SSO and Okta Universal Directory (16:24)

Learn how to implement an ABAC model in AWS by using identity federation with Okta Universal Directory and AWS IAM Identity Center (successor to AWS SSO).

Fine-grained access control with Amazon Cognito identity pools (20:20)

Learn how to implement fine-grained access control with Amazon Cognito identity pools, and watch a demo of using attributes from IdPs.

Use cases

Grant developers and workloads read and write access to only their project resources

When you base permissions on user attributes, you can ensure that developers and workloads have read and write access to only the resources that belong to their projects. If developers’ or workloads’ attributes match those of the project resources, the developers or workloads are allowed access. Otherwise, they are denied. For example, you can assign developers from two different teams, Alejandro and Mary, to the same IAM role, and then choose the team name attribute for access control. When Alejandro and Mary sign in to AWS, their identity provider (IdP) sends their team name as an attribute in the AWS session, and Alejandro and Mary are granted access to only their team’s project resources as indicated by the tags on those resources.

Mary and Alejandro also could be restricted to create IAM roles that have their respective team name set as a tag, so workloads they create on AWS can access only the resources that belong to their teams.

Ensure that permissions are granted based on IAM attributes when accessing shared resources

When you base permissions on attributes, you can control the level of access a user has to shared AWS resources. For example, by using the same IAM role, you can grant one developer, John, read-only access to an AWS Secrets Manager secret owned by another developer, Saanvi, on his same team because John’s team attribute is equal to the team tag on Saanvi’s secret. This is possible because their IAM role’s permissions are based on a team name attribute. The secret instance may be tagged as created by Saanvi, so she is granted full access to the secret.

Because entitlements are based on the human user’s attributes and not their role’s permissions, John and Saanvi might be granted the same level of access to that secret across different roles.


Use your corporate directory for ABAC

In addition to storing user credentials, your corporate directory stores user attributes such as cost center, department, and email address. You can configure your IdP to pass in user attributes from your corporate directory as tags in federated AWS sessions.

For example, you can leverage user attributes such as login and department to control access to your EC2 instances and Systems Manager Session Manager.

Your IdP also can include information about the user’s authorization context as attributes in AWS. This information can include elements such as whether the user used multi-factor authentication to authenticate to your IdP.

If you use AWS IAM Identity Center (successor to AWS SSO) to authenticate to your AWS accounts, you also can use ABAC whether or not your AWS SSO instance is connected to an external directory or used standalone.

Use tags to manage and secure access to IAM resources

You can use tags to manage and secure access to more types of IAM resources, such as customer managed IAM policies, Security Assertion Markup Language (SAML) providers, and IAM principals (users and roles). Administrators can assign tags to IAM resources to identify resource owners and grant fine-grained access to these resources at scale by using ABAC. For example, a developer can be blocked from creating, modifying, or attaching IAM policies if their attributes don’t match assigned tags.

Require developers to tag new resources they create

Attributes are used as tags in AWS to help with the discovery, access, and cost allocation of resources. As a result, it is critical that every resource is tagged as part of its creation. Through ABAC, you can ensure that every new resource has the required set of tags applied when it is created. For example, you can require that when your developer Mateo creates a new secret with AWS Secrets Manager, he adds his project tag to the secret. Without this tag, Mateo is not allowed to create the new secret.

Get started

ABAC scales with innovation. You no longer have to update existing policies to allow access to new resources.