RBAC and ABAC with AWS IAM -- AWS IAM in a layman's terms (5)
We talked about how AWS CIP, STS and IAM can serve as the foundation of application authorization in our last post, i.e., how the application gets the temporary credential representing a specific role (i.e., privileges) to access the resources of the applications — an architecture understanding how different building blocks work together under the hood.
Now, we need to strategize how we actually build the authorization mechanism. When talking about application authorizations, we often encounter two concepts RBAC (role-based access control) and ABAC (attribute-based access control).
RBAC: what is it?
With Role-based access control, RBAC, a user’s access privilege is determined which role he is in. We often see roles in applications like user, manager, administrator.
See the diagram below — as simple as it
How/when did we define RBAC in AWS IAM?
In our previous posts, we already alluded concrete RBAC access control strategy without explicitly mentioning it.
First example was what we mentioned in this post, that is to define privileges for group and (try very hard) not to define privileges for users individually — it is kind of RBAC definition for managing your AWS account — here the “IAM Group” is the role (NOTE: here the role is not “IAM Role”, it’s the generic term “role” in authorization)
Another example was what we mentioned in this post, that is application users getting privileges by assuming a role (through getting temporary credentials):
What common practice they share? Privileges of individual user is defined by a role
it could be an IAM role in the application building example;
it could be an IAM group in the internal AWS account user manage example;
ABAC: what is it?
The Attribute-Based Access Control (ABAC) leverages attributes in various components inside the system, rather than the role, to control who / when / where can access a resource.
ABAC provides a much more fine-grained and much more sophisticated access control capability. Instead of defining roles with specific privilege, it relies on a rule engine that evaluate attributes.
There are three types of attributes: user (principal) attributes, resource (asset) attributes, and environment attributes — the the rule engine can define simple rules to achieve complex and fine-grained combination access control rules.
How can we define ABAC in AWS IAM?
There is an example in AWS IAM document about how we can use AWS IAM properties to define attribute-based access control. That’s probably a long example and it deserves a dedicated post to explain it, but let’s get the high level takeaway from it
Use tags in the IAM policy definition to have a rich set of attributes
You can attach tags to IAM resources, including IAM entities (users or roles) and to AWS resources. You can define policies that use tag condition keys to grant permissions to your principals based on their tags.
ABAC access control is very scalable for you to build fine-grained access control policy
ABAC policies are more flexible than traditional AWS policies, which require you to list each individual resource.
For example, we can define tags (i.e., attributes) for AWS entity (say a user) and resource (say an S3 bucket), and define the rule as the following, which is very hard to define (and even it gets defined, it becomes very hard to maintain) with RBAC:
allow users older than certain age to access a piece of content;
allow users from certain geolocation to access a piece of content;
…
10,000 feet high difference between RBAC and ABAC
RBAC is much simple to implement, as we have seen above — actually, the practice in the last post already provide one RBAC implementation;
ABAC provides almost infinite condition scalability (e.g., age > 21, employed by NGO and from US — a hypothetical example here, no real meaning);
ABAC provides highly granular access control.
Summary
We talked about RBAC access control with AWS IAM, which are common cases for a lot of applications, and the common practices we needed in our enterprise app security (we gave two examples).
We also briefly talked that AWS IAM can offer ABAC access control if we need more complex and scalable access control policies — ABAC deserves several dedicated posts itself, but the takeaway from this post should be that AWS IAM tags and conditions offer the tool for us to build such access control policy.