IAM ABAC PrincipalTag Condition Auditor

The Incident (What Does the Error Mean?)

You'll see this surface as an implicit deny in CloudTrail, or worse — no deny at all because the Condition block is absent entirely:

{
  "errorCode": "AccessDenied",
  "errorMessage": "User: arn:aws:iam::123456789012:assumed-role/dev-role/session
  is not authorized to perform: s3:GetObject on resource:
  arn:aws:s3:::prod-data-bucket/reports/q4.csv
  because no identity-based policy allows the s3:GetObject action"
}

Or the inverse — no error at all, meaning a dev-tagged principal is reading prod-tagged S3 objects because the Condition block that should have blocked it was never written.

Immediate consequence: Your entire ABAC model is non-functional. Tag-based segmentation between environments, teams, or data classifications is not being enforced at the IAM evaluation layer.

The Attack Vector / Blast Radius

ABAC on AWS depends on a three-way tag match: the principal must carry a tag, the resource must carry a matching tag, and the policy Condition must explicitly compare them via aws:PrincipalTag. If any leg of that triangle is missing, the policy degrades to either a blanket allow or a blanket deny — both are catastrophic in different ways.

Exploitation path:

1. Attacker compromises a team:payments IAM role via credential leak.
2. Your ABAC policy was intended to restrict that role to only team:payments-tagged resources.
3. Because aws:PrincipalTag/team was never added to the Condition block, the restriction is never evaluated.
4. Attacker laterally moves to team:finance S3 buckets, RDS snapshots, and Secrets Manager entries — all tagged differently, all now accessible.

Blast radius: Every resource in the account that relies on this policy for tag-scoped isolation is now effectively unprotected. In multi-tenant SaaS architectures, this is a full tenant-isolation breach.

Prevention in CI/CD

This class of misconfiguration is fully automatable to catch at PR time.

1. Checkov (IaC scanning — Terraform/CloudFormation)

Checkov rule CKV_AWS_355 flags IAM policies with overly permissive actions, but for ABAC-specific enforcement, write a custom check:

# checkov custom check: enforce PrincipalTag condition on ABAC policies
from checkov.common.models.enums import CheckResult
from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck

class CheckABACPrincipalTag(BaseResourceCheck):
    def __init__(self):
        name = "Ensure aws:PrincipalTag condition is present in ABAC IAM policies"
        id = "CKV_CUSTOM_ABAC_001"
        supported_resources = ["aws_iam_policy"]
        super().__init__(name=name, id=id, categories=[], supported_resources=supported_resources)

    def scan_resource_conf(self, conf):
        policy = conf.get("policy", [{}])[0]
        for stmt in policy.get("Statement", []):
            condition = stmt.get("Condition", {})
            se = condition.get("StringEquals", {})
            if not any("aws:PrincipalTag" in k for k in se.keys()):
                return CheckResult.FAILED
        return CheckResult.PASSED

2. OPA / Conftest (policy-as-code gate in CI)

# opa policy: deny IAM statements without PrincipalTag condition
package aws.iam.abac

violation[msg] {
  stmt := input.Statement[_]
  stmt.Effect == "Allow"
  not principal_tag_condition_present(stmt)
  msg := sprintf("Statement '%v' is missing aws:PrincipalTag condition — ABAC not enforced", [stmt.Sid])
}

principal_tag_condition_present(stmt) {
  keys := object.keys(stmt.Condition.StringEquals)
  startswith(keys[_], "aws:PrincipalTag/")
}

Wire this into your GitHub Actions or GitLab CI pipeline as a blocking gate on any PR that modifies *.json IAM policy files or Terraform aws_iam_policy resources.

3. AWS Config Rule

Deploy a custom AWS Config rule using config:PutConfigRule to continuously evaluate attached policies across all IAM roles in the account for missing PrincipalTag conditions. Flag non-compliant roles in Security Hub for remediation tracking.