Securing Access Through Attribute-Based Access Control (ABAC) in AWS
A deep-dive into ABAC @ AWS
Before we jump into the deep end of access control, it’s helpful to understand the differences between Authentication and Authorisation. It might be old hat for some of you, but it’s good to understand the basics to ensure that we all are on the same page.
Authentication is a mechanism of verifying the identity of a user, process or system and is often a pre-requisite to allowing access to information systems. As they have evolved, authentication tools have become more sophisticated. Organisations have moved away from good old hashing of passwords and storing in database and turned to tools such as Azure Active Directory, Ping Identity, or Okta, amongst others. These tools allow for the seamless management of identities and associated capabilities such as MFA or Password Rotation in a more managed, simple, and reliable manner.
Authorisation refers to the permissions that the authenticated user has to access a resource, capability, or feature. Whilst Authentication refers to “who” the user is, authorisation specifies “what” the user has access to and is entitled to do.
Let’s take an example of Microsoft SharePoint application which most of us are familiar with. I use my Azure AD credentials to log in to SharePoint (authentication) but that doesn’t mean that I’ll get access to a site/space that belongs to my team/division (authorisation). What this means is that if I need access to a particular site within SharePoint, I must be granted authorisation with relevant permissions (read, write, read-write, admin) to manage the site.
Types of Access Control
Now that we understand what Authentication and Authorisation are, let’s find out how it is relevant to cloud, and in particular AWS. The AWS service at the heart of provisioning and managing access is AWS Identity and Access Management (IAM). IAM allows for fine-grained control across all AWS services. IAM Policies help in implementing the right permissions for users and systems using the principle of least privilege to ensure that only the relevant access to resource is granted.
AWS Identity and Access Management (IAM) service supports two authorisation strategies:
Role-Based Access Control (RBAC): This is a traditional authorisation strategy which defines permissions based on person’s job function or role. In AWS, IAM role is an identity that can be assumed by a user or a service. You would implement RBAC in IAM by implementing different policies for different job functions and then attaching the policies to IAM roles, users or groups.
Attribute-Based Access Control (ABAC): This is a more advanced authorisation strategy where authorisation is based on resource and user attributes. In AWS, these attributes are called tags. You can attach tags to most AWS resources, including IAM resources (roles or users). A single policy or set of ABAC policies can be created for IAM Principals. And, if applicable, all IAM Principals can refer to the same policy. These policies are designed to allow operations when the principal’s tag matches the resource tag.
How does RBAC compare to ABAC
The primary benefits of ABAC, when compared to RBAC are:
Better scalability. Using tags to allow access to resources reduces the burden on administrators to change policies when new resources are added or removed from an environment. It also allows SAML-based identity providers to pass user metadata, allowing for seamless access across the AWS environment based on tags. This provides better scalability when we want to drive innovation with different services whilst keeping privilege in check. Also, when a new user is added to an organisation’s directory, it can inherit appropriate tags/keys pertaining to the project or group further easing management of access to AWS services.
Less policy management. Unlike RBAC where we are creating different policies for different job functions, ABAC will allow for fewer policies which will be easier to manage as the access will be granted based on the tags associated to the principal. This means less overhead for creating, managing, and updating policies when requirements change.
Use of employee metadata (attributes) from Corporate Directory. SAML-based or web-based identity providers (like Okta, Ping Identity, etc.) can pass session tags to AWS based on the identity metadata. These tags can then be used to allow or deny permissions to resources. When defining the Conditions within a policy, you can use relevant global context keys (such as aws:PrincipalTag) to define and use these relevant user attributes to allow or deny access to resources.
Implementing ABAC in AWS
The following steps will help you better understand centrally managing access through an Attribute-Based Access Control model pertaining to an IAM user or role.
Step 1: Ensure that you have employed a correct tagging strategy across your resources so that you can see a consistent outcome that you envisage across the entire cloud stack. Some of the common tags across resources can be project, group, environment, cost centre, etc.
Defining needs and use cases — Tagging Best Practices
Step 2: Identify the key services and actions that you would want to be governed via ABAC. It is important to note that NOT all actions are governed through ABAC. This means you can’t enforce policy conditions across all actions for a service. So how do we know which action gets supported by which condition? To answer this question, you need to go through Reference — Service Authorization Reference documentation, select the service (eg : Actions, resources, and condition keys for AWS Secrets Manager — Service Authorization Reference ) and then go through “Actions defined by…” section to evaluate the Action along with the Condition Key.
Step 3 : Apply the policy to any applicable IAM User or Role.
Implementing ABAC in AWS: A Detailed Example
Step 1: Define policy to implement ABAC
In this example, we’ll implement ABAC for AWS Secrets Manager service. This service helps you protect secrets needed to access your applications, services, or IT resources.
We define the policy below to ensure that secrets for a particular team are only accessed by people who belong to the team. As an example, secrets pertaining to the cloud-security team cannot be accessed by the linux-automation team and vice-versa. This is done using the “team” tag on the resource which matches the “team” tag on the IAM Principal.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "SecretsManagerConditions",
"Effect": "Allow",
"Action": "secretsmanager:DescribeSecret",
"Resource": "*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/team": "${aws:PrincipalTag/team}",
"aws:ResourceTag/environment": "production"
}
}
},
{
"Sid": "SecretsManagerList",
"Effect": "Allow",
"Action": "secretsmanager:ListSecrets",
"Resource": "*"
}
]
}Step 2: Create Users (or Roles)
In order to demonstrate access via User Tags, we have created two specific IAM users with the below configuration and associated the relevant tags for the user depending on the team and the group they belong to.
Step 3: Apply policy to the User
ABAC Policy defined in Step 1 to the users in Step 2.
Step 4: Create secrets in AWS Secrets Manager
Use the configuration in the table below:
Step 5: Log into AWS console as the first User, ChrisBurg
Select AWS Secrets Manager from the search bar and click on ‘Secrets’ on the left hand menu bar. The following list of Secrets will appear for the user given there aren’t any conditions applied for the secretsmanager:ListSecret action
Step 5.2: Click on each secret from the above list. Since ChrisBurg belongs to the team linux-automation and the environment for the secret is production, Chris can successfully describe this secret.
Since Chris doesn’t belong to the team cloud-security, an exception/error is returned back on console as it doesn’t adhere to the policy. This is where ABAC is so powerful as we don’t have to have separate roles based on resource but can manage access to resources via applicable tags, granting access only when the tag value matches the condition.
Step 5.3: Click on each secret from the above list. Since DanMalik belongs to the team cloud-security and the environment for the secret is production, Dan can successfully describe this secret.
However, since Dan doesn’t belong to the team linux-automation, an exception/error is returned back on console as it doesn’t adhere to the policy.
Final Thoughts
There’s no doubt that ABAC can help organisations manage permissions at scale. It is certainly built to scale up innovation and reduce administrators’ overhead for policy management. The biggest challenge, however, is that not all actions across AWS services are currently supported by attributes. This leads lead to complex policy management as you will need to implement both ABAC and RBAC approaches. This is something that teams implementing IAM Policies should consider: whether to support both approaches or go with just one, and possibly moving to ABAC once all required actions are supported by attributes.
Moving towards an attribute-based authorisation target state is a journey and taking a step in the right direction is certainly worth considering!
References
What is ABAC for AWS? — AWS Identity and Access Management
Actions, resources, and condition keys for AWS Secrets Manager — Service Authorization Reference
