Attribute-Based Access Control

Attribute-Based Access Control (ABAC) makes authorization decisions by evaluating attributes against policy rules. Attributes can describe the subject requesting access, the target resource, the requested operation, and environmental conditions such as time or network origin. For example, a policy might permit an engineer to read a secret only when the engineer's project attribute matches the secret's project attribute. Authentication establishes who the requester is; ABAC determines what that requester may do.

Cloud implementations commonly represent attributes through identity metadata, resource tags, and temporary-session attributes. In AWS, IAM policies can compare a principal tag such as aws:PrincipalTag/Project with a resource tag through aws:ResourceTag/Project or a service-specific condition key. A shared policy can therefore authorize supported operations on resources belonging to the caller's project without enumerating every resource identifier. Tags alone do not grant access: an applicable policy must explicitly use them, and the requested action must support the relevant condition keys.

Consider an organization running several application teams. Engineers assume a role that permits selected development operations, while a trusted identity provider supplies their project as a session tag. Resources carry a corresponding Project tag. The same role and policy structure can serve multiple teams, with the tag comparison separating their access. A newly created resource can fall within the policy automatically when it has the required attributes, but only if other authorization controls also permit the operation.

Role-Based Access Control (RBAC) instead groups permissions around job functions, such as developer, auditor, or database administrator. ABAC and RBAC are complementary rather than mutually exclusive. A practical hybrid uses roles to define allowed categories of actions and attributes to determine which resources those actions may affect. RBAC is often easier for a small set of stable responsibilities; ABAC reduces repeated policies across many projects but introduces dependencies on attribute quality and governance.

Attribute integrity is a security boundary. An engineer who can change a resource's Project tag or choose an unrestricted session tag might gain access to another team's resources. Restrict who can assign identity attributes, which session-tag keys and values are accepted, and who can add, change, or remove authorization-sensitive resource tags. AWS role trust policies must appropriately authorize session tagging through sts:TagSession. Validate permitted tags during resource creation using supported request-tag and tag-key conditions, and protect subsequent tagging operations separately.

Creation requires special attention because the resource may not yet have tags available for authorization. Use request attributes where the creation API supports them, require mandatory tags, and test operations that create several related resources. Tagging support does not automatically imply support for tag-based authorization, and some actions cannot be restricted by resource tags. Consult each action's authorization capabilities and design separate permissions for unsupported operations.

Troubleshooting should verify the actual session attributes, resource tags, condition operators, action support, and all applicable policies. Missing attributes can cause conditions to fail, while negated operators or IfExists conditions can behave differently from an ordinary equality check. An ABAC allow does not override an applicable explicit deny, and permission boundaries or organizational controls can still constrain access. Test matching, mismatching, missing-tag, and unauthorized-retagging scenarios rather than validating only successful requests.