The state of ABAC on AWS (in 2024)

Feb 25, 24
The state of ABAC on AWS (in 2024)

Scott Piper checked in on “The state of ABAC on AWS” back in 2020. Things are only a little better.

ABAC?

Attribute-based access control (ABAC) bases fine-grained authorization on user and resource attributes. In AWS, this is mediated by Tags, that can store these attributes attached to both Principals and Resources.

ABAC can often be handy for shrinking complex IAM policies, simpifying their conditionals, and dynamically keeping permissions accurate against changing resources.

Recaping “Problems with ABAC”

Let’s take a look at the specific limitations Scott found.

2020 Problem 2024 Status
Lack of privilege support: only ~43% of privileges for creating resources on AWS allow you to both tag the new resources and to restrict what tags are used for that. Notable exclusions: lambda:CreateFunction, dynamodb:CreateTable, kms:CreateKey, logs:CreateLogGroup, s3:CreateBucket, sqs:CreateQueue, and iam:CreateRole. 🚧 Some improvement! We now get ~58% using the same methodology, despite the total number of create permissions almost doubling. Of the explicitly listed actions, only dynamodb:CreateTable and s3:CreateBucket still lack support for RequestTag.
Lack of tooling: tools for analyzing IAM are not ABAC aware 🚧 PMapper has added some minor support for tags. Other popular IAM tools like Cloudsplaining still completely lack support. Modern vendors tend to have strong support for global condition keys (aws:PrincipalTag, aws:ResourceTag and the like). Vendors may not support all resource-specific keys.
SimulatePrincipalPolicy requires you to explicitly specify tags within the “context keys,” reducing its value ❌ Unchanged.
Zelkova ❌ Unchanged.
Limited capabilities of Tag Policies: you cannot enforce that a resource is tagged ❌ Unchanged.
Lack of support for working with multiple tag values ❌ Unchanged.
Lack of transitive tags for the creation of resources ❌ Unchanged.

Expanding on the Problems with ABAC

Lack of Privilege Support

AWS offers a useful overview of Services that work with IAM. This may be a more actionable lens on the limitation Scott noted. Be particularly wary of “Partial” support.

A screenshot of AWS' Services that work with IAM

Andreas Wittig adds some color to this problem over \on LinkedIn:

Only a few services -EC2 for example- allow you to restrict adding tags for new resources only. For example, it is not possible to restrict the kms:TagResource action in a way, so that tags can only be added when creating a new key. So controlling access to KMS keys by using tags is only possible in very static scenarios with a lot of manual effort.

ABAC’s Inconsistent Interface

In addition to lack of pervasive support, AWS also ships their two pizza teams through an inconsistent interface for Tag management.

Here is just a sample of the CRUD permissions across various services:

TagResource / UntagResource / ListTagsForResource
sns:ListTagsForResource, lambda:ListTags, dynamodb:ListTagsOfResource, apigateway:GetTags, kms:ListResourceTags
AddTagsToResource / RemoveTagsFromResource / ListTagsForResource
AddTags / RemoveTags / ListTags, used by CloudTrail
CreateTags / DeleteTags / DescribeTags, used by EC2 and Workspaces
iam:TagUser, sqs:UntagQueue, iam:ListRoleTags
acm:AddTagsToCertificate / acm:RemoveTagsFromCertificate / acm:ListTagsForCertificate

The CLI offers a similarly disjointed syntax for tag management.

As NCC Group’s Rennie deGraaf diagnoses it it:

Tagging support was added to many AWS services well after they were first released and ABAC support was grafted on later still

AWS has tried to address this via AWS Resource Groups Tagging. This has its own (relatively expansive) set of supported services.

Some of the oldest services have even more complicated limitations. For example, S3’s PutObjectTagging and PutBucketTagging work on tag-sets, replacing all tags versus mutating a single key-value pair.

Scaling ABAC

Service Control Policies (SCPs) are a critical element of an AWS ABAC implementation. This reliance exposes AWS ABAC to the common pain points of AWS’s SCP limits (discussed previously: SCP Quotas).

There is no generic set of actions and conditions to “protect sensitive tags,” making SCPs verbose. This is exacerbated by the inconsistent interfaces mentioned above, which introduces substantial per-service configuration within SCP guardrails.

Trying to do Temporary Access with AWS ABAC

One appealing application of ABAC would be for dynamic or temporary permissions. However, in practice I’ve found AWS ABAC ill suited to this purpose.

  1. Principal Tags and Federated Access

For dynamic, just-in-time grants, AWS ABAC is difficult to operationalize when you’re also using federated access via IAM Identity Center.

It’s uncommon that IdPs offer support for programmatically modifying the relevant user attributes, especially not at scale.

  1. Two-Party Access and TTLs

Another possible case for ABAC is two-party access (2PA), also known as the “two-party rule”.

Picture this:

  • You have a set of users who are authorized to take exceptional actions, but only if two people agree
  • So, you allow these users to create an “exception” tag. The tag must store their identity.
  • Once so tagged, any second user can take the action

This would be magical! Unfortunately, AWS ABAC doesn’t offer any way to store TTLs on tags.

The existance of the aws:CurrentTime global condition paired with Date condition operators almost gets you there. But, I haven’t found a way to force creation of a tag with either a set time in the future (i.e “tag with currenttime + 10m”) or to do the comparison against a set window (i.e “tag value is within the last 10m”). The Date condition operators also don’t support policy variables (h/t Scott Pack!).

Let me know if you figure it out!

Both The True Power of AWS Tags: How to Use ABAC at Scale and AWS themselves seem to recommend you implement the TTLs out of band of ABAC. It’s a cool solution, but adds complexity that would be great to avoid!

The Future of ABAC

Looking at the progress since 2024, where do you think we’ll be in 2028?

My realistic hope:

AWS Resource Groups Tagging seems a safer bet for comprehensive coverage than a mass refactor, so that’s where I’d place my bets. Ideally, AWS will also launch a way to natively and generically enforce tagging on resource creation, and will offer a standardized pattern for protecting ABAC-related tags without having to account for all of those disjointed old API actions. Paired with some clean mechanism for temporary access or TTLs, and I think ABAC starts to look a lot more viable.

Until then, it’s a useful tool to be aware of, but the constraints make it hard to recommend broadly or unreservedly.

References