Skip to content

CONCEPT Cited by 1 source

Condition-tag IAM

Condition-tag IAM is the AWS IAM authorization pattern where an IAM policy's effect on a request is gated on AWS resource tags via the Condition element, matching on aws:ResourceTag/<key>, aws:RequestTag/<key>, or aws:TagKeys. The IAM role may hold broad Action + Resource grants but the Condition narrows effective access to only resources (or tag-carrying requests) that match an organisation's tag scheme.

Definition

An IAM policy statement like:

{
  "Effect": "Allow",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::*/*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/Environment": "staging"
    }
  }
}

grants s3:PutObject on any object, but only when the target bucket (or object, depending on the tag-inheritance rules for the service) carries Environment=staging. Resource-tag-based IAM is sometimes called Attribute-Based Access Control (ABAC) in the AWS documentation.

Tag keys can encode:

  • Environment tier: Environment=prod|staging|dev.
  • Data classification: Classification=public|internal|confidential|restricted — see concepts/data-classification-tagging.
  • Team / ownership: Team=payments|analytics|....
  • Cost center: CostCenter=42.
  • Compliance tier: Compliance=pci|hipaa|soc2.

Where this matters

When a vendor's managed-service deploys compute into a customer's cloud account with a scoped IAM role, the customer can use condition-tag IAM to further restrict what the vendor's role can act on even within the actions the role holds. Examples:

  • Redpanda's agent role may hold s3:* on tiered-storage buckets, but the customer adds aws:ResourceTag/Owner=redpanda to the policy — so even if the role is misused, it can only touch buckets tagged Owner=redpanda.
  • The customer may tag some sensitive buckets with Classification=restricted and add a StringNotEquals condition excluding the vendor's role from those — defence in depth beyond bucket policies.

Canonical instance

Redpanda BYOVPC names condition-tag support as one of the four reasons teams choose BYOVPC. Verbatim (Source: sources/2026-03-11-redpanda-redpanda-clouds-byovpc-for-aws-is-now-generally-available):

"Support for condition tags for fine-grained IAM controls based on AWS resource tags."

No mechanism depth in the post — just a capability assertion that the BYOVPC provisioning path composes with condition-tag IAM scoping. Presumably the Redpanda Terraform module's instance-profile policies allow customers to extend them with additional Condition clauses, or the customer adds a separate permissions-boundary policy with condition-tag restrictions.

Trade-offs

  • Policy evaluation cost: condition evaluation per request adds IAM evaluation time. Negligible in practice but matters for extremely high-QPS services.
  • Tag-drift risk: if resources lose their tags, they become inaccessible. Requires tag-lifecycle automation (e.g. enforce tagging at creation via SCPs, periodic tag-compliance audits).
  • Tag-spoofing surface: aws:RequestTag/* conditions gate on the tags the caller passes at request time, not on already-applied resource tags. Needs aws:TagKeys / iam:PassedToService guards to prevent tag-laundering.
  • Requires per-service tag-support matrix: not every AWS action supports tag-based conditions. The service-specific IAM docs enumerate which.

Composes with

  • Permissions boundary: condition-tag IAM restricts what a role can do within its policies; a permissions-boundary policy caps the maximum possible. BYOVPC's Terraform module provisions a permissions-boundary policy (permissions_boundary_policy_arn).
  • Data classification tagging — see concepts/data-classification-tagging. Classification tags encoded on resources drive IAM conditions that gate vendor role access to classified data.
  • IAM footprint minimization — see concepts/customer-managed-iam-footprint-minimization. Condition-tag IAM is the spatial-scoping complement to the broader posture-minimization principle.

Seen in

Last updated · 470 distilled / 1,213 read