AWS recently announced Attribute-Based Access Controls support for AWS Simple Notification Service. What is Attribute-Based Access Controls and does it replace existing controls? This blog post will explain the differences between Role-Based Access Controls and Attribute-Based Access Controls using SNS and how it can help to scale your organization, development team and applications.

What are Role-Based and Attribute-Based access controls? 

Permissions and access management on AWS are an example of a shared responsibility. It is your responsibility to specify which entities are allowed to perform which actions on specific resources and under which conditions. The role of AWS is to enforce these permissions by evaluating each request. There are two strategies to define permissions: Attribute-Based Access Controls (ABAC) and Role-Based Access Controls (RBAC).

RBAC follows a more traditional model where the permissions required for a role outside of AWS is mapped onto an AWS IAM role, aligning the permissions that the outside role requires with an “internal” IAM role. For example, developers working on project “Unicorn” will require a role that allows access to the resources of that specific project. When additional resources are added to the “Unicorn” project, then the IAM role will need to be updated. If a developer leaves the “Unicorn” project, the developer must have the role for the project removed and probably a new role assigned.

This example demonstrates that RBAC will require constant evaluation of the permissions as the project and team is growing. Despite this overhead, RBAC is very popular and provides many benefits:

1. Grant fine-grained user-specific permissions by assigning a collection of roles
2. Create a distinct role for each unique combination of permissions
3. Determine access by auditing specific role permissions

To help organizations to scale their authorization strategy, AWS introduced ABAC. This access control defines permissions based on attributes. Attributes can be a key or a pair of key and value. These key/value pairs are known as “tags” in AWS and can be attached to both IAM resources and AWS resources. Common use cases for tags are auditing, cost control and resource ownership. Using ABAC, you can leverage your tags for permissions and access management.

Going back to the example of the developer working on the “Unicorn” project, with ABAC, the developer’s IAM role could be tagged with “Project” as key and “Unicorn” as value. Same with the resources assigned to the project. This will allow you to create a more general IAM policy that is highly dynamic and with conditionality built-in. This policy can easily be reused across multiple projects and teams.

The main benefits that ABAC provides over RBAC are:

1. Permissions scale easily with the growth of the team, organization and application(s)
2. Fewer IAM policies are required
3. The best practice of least privilege can also be enforced using ABAC. You can scope which tagged resources can be accessed.
4. Using session tags, you can add attributes from your SAML-based or web identity provider as tags to federated AWS users, granting them access to tagged resources.
   
   

ABAC examples

The next part of this blog post will demonstrate some functionality provided by ABAC using AWS Simple Notification Service:

• Restricting access to resources based on principal tag
• Restricting access to resource based on resource tag
• Force users to set a tag on when a resource is created

Simple Notification Service, or SNS, is a fully managed messaging service for both application-to-application or application-to-person communication. The service can be used to set up event-driven, push-based, serverless workloads. AWS recently announced ABAC support, which makes it an ideal candidate to demonstrate some of ABAC’s capabilities.

There are 2 users present in the demo, demo-team-green and demo-team-red, which belong to the demo-abac-sns IAM group.

The examples will require some inline policies to be added to the IAM group. You can add inline groups in the AWS console by navigating to User groups in the IAM section of the AWS console. In the Permissions tab, you will be able to create an inline policy.

The group has the following inline permissions attached to it:

With these permissions, the users will be able to navigate to the SNS section in the AWS Console and see all the existing topics for the account.

Restricting access to resources based on principal tag

Using ABAC, you can leverage access to your resources based on the tags assigned to the principal. A principal is an entity that is either allowed or denied access. In this demo, the principal will be an IAM user. The user demo-team-red will be assigned a tag.

Add the following policy as inline policy to the IAM group:

Note the “aws:PrincipalTag/team”: “red” condition. This requires the principal to have a tag with key team and value red to be able to perform the action; otherwise, the principal will be denied access. Attempting to create a topic with the demo-team-green user will result in an error. Creating a topic with the demo-team-red user will be successful.

Relying on attributes to grant permissions to manage resources is one of the best practises using ABAC.

Restricting access to a resource based on a resource tag

You can restrict access to a resource based on the resource tag attached to a resource. Start with creating a team-blue-topic tagged with a key team and value blue.

Next, add the next statements as an inline policy to the IAM group:

This policy will deny any deletes on topics tagged with the tag pair team:blue. At this time of writing (1 February 2022), the AWS console still renders a warning that this condition is not supported.

You can validate this action by deleting the topics generated from previous demonstrations with either demo-team-red or demo-team-green user. Trying to delete the team-blue-topic tagged with the resource tags will result in an error. This demonstrates ABAC capabilities to allow or deny access to resources based on the tags attached to the resource. A best practice when working with resource tags is to audit your resources regularly to validate if they are tagged correctly.

Force users to set a tag when a resource is created

Tagging each resource can be cumbersome, especially if usage is limited to a specific group of users. You can automate this process by forcing users to tag the resource with a specific tag when they create resources.

Demo-team-red will be able to create a topic and will be required to provide a tag when creating the resource. Add these statements as inline policy to the IAM group.

The aws:RequestTag indicates the tags that are required in the request. The value is dynamically set from the value extracted from the tag assigned to the principal. This is an example on how ABAC can be highly dynamic and easily reusable for different teams and projects. 

Trying to create a topic as the demo-team-red user without providing any resource tags or a key/value pair that is not equal to team/red, will result in an error. This demonstration is an example of another recommendation by AWS. Tag everything during creation so that permissions apply immediately.

Automatically allow actions on created and tagged resources

The previous three examples each showed some capabilities of ABAC. In this final example, a user is only allowed to publish on topics it has created with its appropriate tag. This means that a demo-team-red will only be able to publish on topics with key/value team/red and only this user will be able to create these topics.

Start by removing all the existing inline policies attached to the IAM group. Add the following policy as inline policy to the IAM group:

This policy will allow users to publish messages on a topic when the aws:ResourceTag team tag matches the team tag attached to the user. 

Add another inline policy to allow the demo-team-green user to create topics. Do not forget to assign a team/green tag to the demo-team-green IAM user.

You should be able to create a topic with both users, assigning their respective team as tags to the topics. Each user should be able to publish on its own topic. Trying to publish a message on the topic of the other user will result in an error.

The examples show that using ABAC allows to quickly change permissions and access to resources using highly dynamic policies with conditions like aws:RequestTag and aws:ResourceTag.

Key takeaways

ABAC is less cumbersome than RBAC and will greatly simplify your resources access and permission strategy. The examples demonstrated some of the powerful capabilities that ABAC provides. As mentioned in the examples, there are a few guidelines AWS provides when working with ABAC:

1. Reserve a subset of attributes for access control.
2. Strict control on what/who can update attributes
3. Tag everything during creation so that permissions apply immediately
4. Rely on attributes to grant permissions to manage resources
5. Audit your resources regularly to validate if they are tagged correctly

Note that not every AWS service supports ABAC. You can use this list (https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) to see if a service supports ABAC. When a checkmark is present in the Authorization based on tags column, then it’s available for ABAC.

Interested in working together? 

Get in touch