Conditions, ABAC and Delegation

What it is

Conditions make a policy statement apply only in certain situations, such as from a specific network, with MFA, or when a resource tag matches a principal tag. They turn a broad permission into a precise one without writing a statement per resource.

This page covers the condition language, attribute based access control (ABAC), and how to let teams create their own roles safely.

How it works

Condition structure

A condition block has an operator, a key and one or more values.

"Condition": {
  "StringEquals": { "aws:RequestedRegion": ["eu-west-1", "eu-central-1"] },
  "Bool": { "aws:SecureTransport": "true" }
}

The logic rules are easy to test.

• Several operators or keys in one block combine with AND.
• Several values for one key combine with OR.
• Add IfExists to an operator to treat a missing key as a match, which matters in deny statements.
• ForAnyValue and ForAllValues apply to keys with multiple values. ForAllValues is true when the key is absent or empty, so combine it with a check that the key exists.
• Negated operators such as StringNotEquals in a deny statement are a common way to write an exception.

Useful global condition keys

Network keys such as aws:SourceIp apply to the original caller. If an AWS service makes a call on the caller's behalf, the source is the service, so a deny based on IP can break service integrations unless you add aws:ViaAWSService.

Attribute based access control

ABAC grants access when tags match, so permissions scale without editing policies. One policy serves every project.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["ec2:StartInstances", "ec2:StopInstances"],
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": { "StringEquals": { "aws:ResourceTag/project": "${aws:PrincipalTag/project}" } }
  }]
}

A user tagged project=Alpha can start and stop only instances tagged project=Alpha. New projects need only new tags.

Compare the two models.

ABAC fails if people can change tags. Protect tag keys used for authorisation, by denying tag changes except for a trusted role, and use aws:RequestTag and aws:TagKeys to control tagging at creation. Identity Center and federation can pass user attributes as session tags to feed the principal tag.

Safe delegation with permissions boundaries

Developers often need to create roles for their applications, but they must not create roles that exceed their own limits. Combine a permissions boundary with a condition on role creation.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["iam:CreateRole", "iam:AttachRolePolicy", "iam:PutRolePolicy"],
      "Resource": "arn:aws:iam::111122223333:role/app-*",
      "Condition": { "StringEquals": { "iam:PermissionsBoundary": "arn:aws:iam::111122223333:policy/DevBoundary" } }
    },
    {
      "Effect": "Deny",
      "Action": ["iam:DeleteRolePermissionsBoundary", "iam:DeleteUserPermissionsBoundary"],
      "Resource": "*"
    }
  ]
}

The first statement allows role creation only when the boundary is attached, and the second stops the boundary being removed. Developers can then create roles within the limit and cannot escape it.

Controlling PassRole

iam:PassRole lets a principal give a role to a service. Without limits, a user can pass an administrator role to a Lambda function or EC2 instance and use it to escalate. Limit the resource to specific role ARNs, and use iam:PassedToService to name the service.

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::111122223333:role/app-lambda-*",
  "Condition": { "StringEquals": { "iam:PassedToService": "lambda.amazonaws.com" } }
}

Data perimeter conditions

A resource policy can restrict a bucket to your organization with aws:PrincipalOrgID, and an identity policy or SCP can limit users to resources in your organization with aws:ResourceOrgID. Together with network conditions, these form a perimeter that keeps data in and untrusted identities out.