This is a guest blog post from Shuo Yang in his blog series “Transitioning to Programming the Cloud”, as a part of our blog posts focusing on Identity, Security and Access.

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 determines which role he is in. We often see roles in applications like user, manager, administrator.

See the diagram below — as simple as it

AWS Bucket

How/when did we define RBAC in AWS IAM?

In our previous posts, we already alluded to concrete RBAC access control strategy without explicitly mentioning it.

The 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 an 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.)

AWS Bucket

Another example was what we mentioned in this post; that is, application users getting privileges by assuming a role (through getting temporary credentials):

Auth Role Pool

What common practices do they share? Privileges of individual user are defined by a role:

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.

ABAC Rule Engine

There are three types of attributes: user (principal) attributes, resource (asset) attributes, and environment attributes — 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 deserves a dedicated post to explain it, but let’s get the high-level takeaway from it

  1. Use tags in the IAM policy definition to have a rich set of attributes

    For example, 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.

  2. ABAC access control is very scalable for you to build a fine-grained access control policy

    For example, we can define tags (i.e., attributes) for AWS entity (such as a user) and resource (such as an S3 bucket), and define the rule as the following, which is very hard to define (and even if it gets defined, it becomes very hard to maintain) with RBAC:

AWS Tags and Rule Engine

Teleport cybersecurity blog posts and tech news

Every other week we'll send a newsletter with the latest cybersecurity news and Teleport updates.

10,000 feet high difference between RBAC and ABAC

Implementation Simplicity Simple Complex
Dimension Scalability Low High
Access Granularity Low High


We talked about RBAC access control with AWS IAM, which is a common case for a lot of applications, and the common practices we needed in our enterprise app security (we provided two examples).

We also briefly mentioned 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 an access control policy.

Related Posts

programming cybersecurity

Try Teleport today

In the cloud, self-hosted, or open source

View Developer Docs

This site uses cookies to improve service. By using this site, you agree to our use of cookies. More info.