9.3 Attribute-Based Access Control (ABAC) with IAM Tags

9.3 Attribute-Based Access Control (ABAC) with IAM Tags

As enterprise cloud footprints expand to encompass hundreds of microservices, multiple development teams, and segregated lifecycle environments, managing access through traditional Role-Based Access Control (RBAC) becomes unsustainable. In pure RBAC models, every new project, department, or environment requires creating and maintaining distinct IAM roles and policies. This operational anti-pattern—known as role explosion—creates governance paralysis, increases audit complexity, and heightens the likelihood of overly permissive configurations.

Attribute-Based Access Control (ABAC) solves role explosion by evaluating metadata attributes (represented as tags in AWS) attached to both the calling principal and the target resource. With ABAC, security teams author a small set of generic, reusable IAM policies that dynamically authorize access based on matching attributes. As new resources and personnel are added to the organization, access is granted automatically through consistent tagging without modifying a single IAM policy.

---

RBAC Limitations vs. ABAC Scalability

To appreciate the architectural necessity of ABAC, consider an organization with 50 project teams, 3 operating environments (Development, Staging, Production), and 4 infrastructure tiers (Compute, Storage, Database, Networking):

• Under an RBAC model, the organization must provision and manage:
  50 projects × 3 environments × 4 tiers = 600 unique IAM roles
  Each role requires bespoke policy statements hardcoding specific resource ARNs or paths. When a new project launches, engineers must open administrative tickets to provision new roles and policies.
• Under an ABAC model, the organization deploys a single generic IAM policy attached to a shared role. The policy permits an action only if the principal's Project and Environment tags match the target resource's Project and Environment tags. When a new project is created, administrators simply tag the new resources and user identities; no IAM modifications are required.

---

The Core IAM Tag Condition Keys

The AWS authorization engine provides four primary condition keys that form the foundation of ABAC policies:

Loading diagram...

1. aws:PrincipalTag/${TagKey}

Evaluates tags attached to the identity making the API call. If an IAM user has the tag CostCenter=104, the condition key aws:PrincipalTag/CostCenter resolves to "104". For federated sessions (SAML 2.0 or OIDC), principal tags are populated dynamically from directory attributes.

2. aws:ResourceTag/${TagKey}

Evaluates tags attached to the AWS resource being accessed. For example, if an Amazon S3 bucket or Secrets Manager secret has the tag Department=Engineering, the condition key aws:ResourceTag/Department resolves to "Engineering".

3. aws:RequestTag/${TagKey}

Evaluates tags being passed in the API call itself during resource creation (e.g., ec2:RunInstances, secretsmanager:CreateSecret) or during tagging operations (ec2:CreateTags).

Critical Exam Distinction: During resource creation (such as ec2:RunInstances), the resource does not exist yet at the moment of evaluation. Therefore, aws:ResourceTag cannot be evaluated during creation! You must use aws:RequestTag to enforce that the caller tags the new resource properly upon launch.

4. aws:TagKeys

Evaluates the set of tag keys included in the API request. It is used in conjunction with set operators (ForAllValues and ForAnyValue) to enforce mandatory tagging and block unauthorized tag keys:

• ForAllValues:StringEquals: { "aws:TagKeys": ["Department", "Project", "Environment"] }: Asserts that every tag key included in the request is in the allowed list (prevents rogue tags). It does not require any key to be present, and it also evaluates to true when the request has no tags, so pair it with aws:RequestTag/<key> conditions (or a Null check) to make a tag mandatory.
• ForAnyValue:StringEquals: { "aws:TagKeys": ["Department"] }: Asserts that at least one of the specified tag keys is present in the request.

---

Constructing Scalable ABAC Policies

ABAC policies achieve flexibility through policy variable interpolation. By referencing ${aws:PrincipalTag/TagKey}, an IAM statement dynamically injects the caller's attribute into the authorization evaluation.

Below is a complete, production-grade ABAC policy granting developers access to Amazon EC2 and AWS Secrets Manager:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadMetadataForConsoleNavigation",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "secretsmanager:ListSecrets"
      ],
      "Resource": "*"
    },
    {
      "Sid": "AllowManageMatchingResources",
      "Effect": "Allow",
      "Action": [
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:RebootInstances",
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}",
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    },
    {
      "Sid": "EnforceTagsOnResourceCreation",
      "Effect": "Allow",
      "Action": [
        "ec2:RunInstances"
      ],
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestTag/Department": "${aws:PrincipalTag/Department}",
          "aws:RequestTag/Project": "${aws:PrincipalTag/Project}"
        },
        "ForAllValues:StringEquals": {
          "aws:TagKeys": [
            "Department",
            "Project",
            "Environment"
          ]
        }
      }
    },
    {
      "Sid": "AllowRunInstancesInfrastructure",
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": [
        "arn:aws:ec2:*:*:subnet/*",
        "arn:aws:ec2:*:*:network-interface/*",
        "arn:aws:ec2:*:*:security-group/*",
        "arn:aws:ec2:*:*:key-pair/*",
        "arn:aws:ec2:*:*:volume/*",
        "arn:aws:ec2:*:*:image/*"
      ]
    },
    {
      "Sid": "DenyUnauthorizedTagModification",
      "Effect": "Deny",
      "Action": [
        "ec2:CreateTags",
        "ec2:DeleteTags"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Owner": "${aws:PrincipalTag/Owner}"
        }
      }
    }
  ]
}

Architectural Breakdown of Policy Statements

• Statement 1: Allows global describe and listing operations. Console navigation requires reading resource lists without tag filtering, as AWS console listing APIs rarely support condition keys.
• Statement 2: Enforces the core ABAC match. A principal in Department=FinTech working on Project=PayEngine can only start, stop, or read secrets from resources that carry identical Department and Project tag values.
• Statement 3: Restricts ec2:RunInstances on the instance ARN. The caller cannot launch an instance unless they tag it at launch time with their own Department and Project principal tag values, and they cannot pass any tag keys outside the approved set.
• Statement 4: Permits ec2:RunInstances on auxiliary infrastructure (subnets, AMIs, security groups) where tag matching is not required.
• Statement 5: Protects against tag tampering. A user cannot add or delete tags on an existing resource unless they are the designated owner, closing the privilege escalation backdoor.

---

Enterprise Identity Federation & Transitive Session Tags

In enterprise environments, maintaining IAM users is an anti-pattern. Instead, identities federate from central Identity Providers (IdPs) like Okta, Microsoft Entra ID, or PingFederate using SAML 2.0 or OpenID Connect (OIDC).

Loading diagram...

The SAML PrincipalTag Namespace

During SAML authentication, the IdP injects user directory attributes into the SAML assertion using the standardized AWS attribute namespace:

<saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department">
  <saml2:AttributeValue>FinTech</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Project">
  <saml2:AttributeValue>PayEngine</saml2:AttributeValue>
</saml2:Attribute>
<saml2:Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys">
  <saml2:AttributeValue>Department</saml2:AttributeValue>
  <saml2:AttributeValue>Project</saml2:AttributeValue>
</saml2:Attribute>

The Mandatory sts:TagSession Action

For an IAM role to accept session tags from an external IdP or AssumeRole call, the role's Trust Policy must explicitly permit the sts:TagSession action. Omitting sts:TagSession causes the federation request to fail immediately:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::111122223333:saml-provider/OktaIdP"
      },
      "Action": [
        "sts:AssumeRoleWithSAML",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
      }
    }
  ]
}

Transitive Session Tags Across Role Chaining

When an assumed role assumes another role (role chaining), session tags are discarded by default. If an application assumes Role A and then Role A assumes Role B, downstream calls made by Role B lose the original principal tags, breaking ABAC evaluations.

To preserve session tags across role chains, tags must be configured as Transitive Tags:

• In SAML assertions: include https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys.
• In STS CLI/SDK calls: pass the --transitive-tag-keys parameter during sts assume-role.
• Transitive tags persist across subsequent role assumption steps, maintaining consistent identity context throughout multi-tier service calls.

---

Specialty Exam Pitfalls & Architectural Traps

1. The aws:ResourceTag Creation Trap: Attempting to evaluate aws:ResourceTag on resource creation actions (such as ec2:RunInstances or secretsmanager:CreateSecret). At the moment creation is evaluated, the resource does not exist in the database, so aws:ResourceTag is null and evaluates to false. Always use aws:RequestTag for creation APIs.
2. The CreateTags Privilege Escalation Vector: If a user possesses unconstrained ec2:CreateTags permissions, they can modify the Department or Project tag on an existing production database or EC2 instance to match their own principal tag, granting themselves unauthorized management access. Always restrict or condition CreateTags and DeleteTags.
3. Tag Case-Sensitivity Failures: AWS tag keys and tag values are strictly case-sensitive. If an IdP emits Department=FinTech but an EC2 instance is tagged with Department=fintech, a StringEquals condition will fail. To mitigate this, enforce casing via AWS Organizations Tag Policies or use StringEqualsIgnoreCase where supported.
4. The Missing sts:TagSession Trust Policy Trap: In federation scenarios, engineers frequently configure SAML attributes correctly in Okta or Entra ID but forget to add sts:TagSession to the IAM role trust policy. The federation attempt fails with AccessDenied during AssumeRoleWithSAML.
5. Services Without Tag-Based Condition Support: Not all AWS services support ABAC condition keys. For example, AWS CloudTrail, Amazon Route 53 private zones, and IAM role creation have limited or no support for aws:ResourceTag authorization. In enterprise architectures, ABAC must be paired with RBAC in a hybrid model to govern unsupported services.