Simplify AWS IAM at Scale with Attribute-based Access Control - Impetus

Simplify AWS IAM at Scale with Attribute-based Access Control

Access control remains one of the biggest challenges of application security. Role-based access control (RBAC) and attribute-based access control (ABAC) are the most used access control models for system authorization, both of which have their own advantages. This blog details why ABAC scores over RBAC for Identity and Access Management (IAM) at scale.

For role-based access control (RBAC), the administrator sets up pre-defined roles and policies. However, as new resources get added to the system, the administrator needs to manually update policies for allowing access to those resources. On the other hand, attribute-based access control (ABAC) relies on a rule engine that evaluates attributes and allows or denies access based on metadata (“tags” in AWS parlance) attached to the principals and resources involved in each request.

RBAC or ABAC – which is a better choice?

Let’s assume that you have an application with two development teams – “Yellow” and “Blue” – both of which are scaling up rapidly. You need to develop an IAM solution for the application to ensure that the Lambda function/users of each team can access ONLY their resources. Additionally, as the application scales, the IAM solution should be able to manage the access dynamically with minimal effort.

RBAC approach

With RBAC, you can create an IAM role for each team and attach a policy that grants access to the team’s resources, as shown in the diagram below:

RBAC approach policy

Simple right?

Yes, if it is only two teams. But how will you handle IAM when the number of teams scales up to 100 or 1000? Your administrators will have to create and manage an IAM policy for each development team, which is a huge administrative burden.

ABAC approach

Another approach would be to control access through tagging. You could create an IAM role for each team but attach a single (same) IAM policy to all of them that works by comparing the principal tags with the resource tags. You can use the policy condition detailed in the diagram below:

If the condition evaluation returns true, i.e., if the IAM user’s application tag matches the resource application tag, access will be granted. With this approach, fewer policies are easier to manage.

ABAC approach policy

Scaling is simpler with ABAC

  • Resource scaling: When the Yellow team adds an additional SQS queue, they just need to create the queue with “Application: yellow” tag. The Yellow team will then be able to access this resource without any policy change as the tag values match.
  • Team/application scaling: This approach also makes it easy to add a new team, say, Green. The IAM administrator can simply create a new role “Application = green” tag and use the same policy while tagging other Green team resources.
  • Security Assertion Markup Language (SAML) integration: You can configure your SAML-based or web identity provider to pass session tags to AWS. For employees federated with AWS, the attributes are applied to their resulting principals in AWS. You can then use ABAC to allow/deny permissions based on those attributes.

Choose a lab aligned to your Data & AI journey

Address your desired use case across critical analytic dimensions

  • Explore architecture options with experts

  • Ensure strategic alignment of business and technology

  • Architect an ideal solution for a pressing problem


  • Validate new or refactor existing architecture

  • Develop a prototype with expert guidance

  • Establish a roadmap to production


Learn more about how our work can support your enterprise

Author
Aditi Bhargava