Attribute-Based Access Control (ABAC) in AWS

Attribute-Based Access Control (ABAC) is an authorization strategy that defines permissions based on attributes (tags) associated with the principal (user or role), the resource, and the environment (e.g., time of day). Unlike Role-Based Access Control (RBAC) which assigns permissions to roles that users assume, ABAC uses policies with conditions that evaluate these attributes at runtime. This makes ABAC more dynamic and scalable because you can write a single policy that grants access to any resource that has matching tags, without needing to update the policy when new users or resources are added.

ABAC is particularly useful in large, multi-team AWS environments where resources and users are constantly changing. For example, a developer in the 'project-alpha' team should only access S3 buckets tagged with 'project-alpha'. With ABAC, you create one policy that grants access to S3 buckets where the bucket's 'project' tag equals the user's 'project' tag. When a new developer joins project-alpha, you tag them with 'project=alpha', and the policy automatically applies.

ABAC relies on IAM policies with condition keys that evaluate principal, resource, and request attributes. The key condition keys are: - aws:PrincipalTag: A tag on the IAM user or role making the request. - aws:ResourceTag: A tag on the resource being accessed. - aws:RequestTag: A tag passed in the request (e.g., when creating a resource). - aws:TagKeys: The set of tag keys in the request.

When a request is made, AWS evaluates the policy. The policy might say: "Allow s3:GetObject if the resource tag 'project' equals the principal tag 'project'." At runtime, AWS retrieves the principal's tags (e.g., project=alpha), retrieves the resource's tags (e.g., project=alpha), and checks if they match. If they do, access is granted.

To implement ABAC, you need: 1. Tags on principals (IAM users/roles): Each principal must have tags that define their attributes. For example, department=engineering, project=alpha. 2. Tags on resources: Each resource must have tags that match the principal's tags. For example, an S3 bucket with project=alpha. 3. IAM policy with condition keys: The policy must use conditions like StringEquals to compare principal and resource tags. Example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/project": "${aws:PrincipalTag/project}"
        }
      }
    }
  ]
}

Note the use of ${aws:PrincipalTag/project} – this is a policy variable that resolves to the value of the principal's project tag at runtime.

Policy variables are a critical feature for ABAC. They allow you to substitute the value of a principal tag or resource tag in a condition. The syntax is ${aws:PrincipalTag/tagkey} or ${aws:ResourceTag/tagkey}. AWS supports policy variables only in the Condition block, not in the Resource or Principal elements. This is a common exam trap: candidates think they can use policy variables in the Resource ARN, but that is not supported.

To verify ABAC setup, use the IAM policy simulator or the AWS CLI. For example, to test a policy with a specific principal:

aws iam simulate-principal-policy \
    --policy-source-arn arn:aws:iam::123456789012:user/Alice \
    --policy-input-list file://policy.json \
    --action-names s3:GetObject \
    --resource-arns arn:aws:s3:::example-bucket/object.txt

You can also use the --context-entries parameter to simulate principal and resource tags:

aws iam simulate-custom-policy \
    --policy-input-list file://policy.json \
    --action-names s3:GetObject \
    --resource-arns arn:aws:s3:::example-bucket/object.txt \
    --context-entries "ContextKeyName=aws:PrincipalTag/project,ContextKeyValues=alpha,ContextKeyType=string"

ABAC integrates with: - IAM Roles: You can tag roles and use ABAC to control which resources they access. - S3 Bucket Policies: Use aws:PrincipalTag in bucket policies to grant cross-account access based on tags. - AWS Organizations: Use ABAC in SCPs to restrict access based on tags across accounts. - AWS STS: When assuming a role, the role's tags are used, not the original user's tags. This is a common exam point: if a user assumes a role, the principal tags are the role's tags, not the user's.

You can combine multiple conditions to create fine-grained access. For example, allow access only if the principal's department tag matches the resource's department tag AND the request is made during business hours:

{
  "Condition": {
    "StringEquals": {
      "aws:ResourceTag/department": "${aws:PrincipalTag/department}"
    },
    "IpAddress": {
      "aws:SourceIp": "10.0.0.0/8"
    }
  }
}

The exam often asks you to choose between ABAC and RBAC. Remember: - RBAC: Permissions are tied to roles. You create roles like 'Developer' and 'Admin', and assign users to roles. When a new project starts, you might need a new role. - ABAC: Permissions are tied to tags. You create one policy that uses tags, and you tag users and resources accordingly. When a new project starts, you just tag the new users and resources with the project tag.

The exam scenario will describe a growing environment with many projects and teams. The correct answer is usually ABAC because it scales better without requiring policy updates.

A large company has dozens of projects, each with its own S3 bucket. They have hundreds of developers who move between projects. Using RBAC, they would need to create a role per project and update permissions whenever a developer changes projects. With ABAC, they tag each developer with project=project-name and each bucket with project=project-name. A single policy grants s3:GetObject and s3:PutObject to any bucket where the bucket's project tag matches the user's project tag. When a developer switches projects, an admin simply updates the user's tag. The policy does not change. This reduces administrative overhead and prevents accidental access to other projects' data. In production, they also add a condition to restrict access to corporate IP ranges using aws:SourceIp.

A DevOps team manages EC2 instances for different application teams. Each instance is tagged with team=frontend or team=backend. The DevOps team wants to allow each application team to start/stop their own instances but not others. They create an IAM policy that grants ec2:StartInstances and ec2:StopInstances only if the instance's team tag equals the principal's team tag. They also add a condition to allow ec2:DescribeInstances for all instances (so teams can see all instances). This policy is attached to an IAM group for each team. When a new team member joins, they are added to the group and tagged with the correct team value. If an instance is mis-tagged, the team cannot manage it, which enforces tag accuracy.

ABAC does not introduce significant performance overhead because tag evaluation is done at the IAM policy engine, which is designed for high throughput. However, there is a limit of 50 tags per principal/resource, and the policy size limit is 6,144 characters for identity-based policies. For very large environments with thousands of tags, consider using AWS Organizations tag policies to enforce consistent tagging. Common misconfigurations include: tagging inconsistencies (e.g., case differences), using policy variables in the Resource element (which is unsupported), and forgetting that role assumption changes the principal's tags to the role's tags.