What Is Attribute-Based Access Control? Policy From Attributes

Attribute-based access control (ABAC) makes access decisions by evaluating attributes of the requester, the resource, and the surrounding context against policy rules.

Attribute-based access control, or ABAC, is a flexible authorization model. Rather than mapping users to fixed roles, ABAC evaluates rules over attributes: who is asking, what they are touching, and the conditions of the request. It shines when access needs to depend on context, which is increasingly common in cloud and CI/CD systems.

How ABAC decides

A policy engine evaluates rules like "allow if the user department matches the resource owner and the request comes from a trusted network." The inputs are attributes; the output is allow or deny. This lets one policy cover many cases without enumerating every user.

The attribute categories

Subject attributes: role, team, clearance.
Resource attributes: owner, sensitivity, environment.
Context attributes: time, location, request origin.

ABAC versus RBAC

RBAC is simpler and easier to audit but can explode into many narrow roles when access depends on context. ABAC handles context cleanly but can be harder to reason about. Many real systems start with RBAC and layer ABAC-style conditions for the fine-grained cases.

ABAC in CI/CD

Cloud trust policies often use attribute conditions: a pipeline may assume a role only if the OIDC token attributes show a specific repository, branch, and environment. That is ABAC in practice, restricting access based on the identity of the workload, not just a static role.

Strengths and trade-offs

ABAC scales to complex rules and reduces role sprawl, but policies can become opaque and hard to test. Clear policy authoring, testing, and review are essential, otherwise a subtle rule can grant more than intended.

ABAC and ephemeral runners

Because pipeline OIDC tokens carry attributes about the job, ABAC conditions can pin access to exactly that context. On ephemeral runners (such as Latchkey managed runners), the attributes describe a single short-lived job, so access granted by policy expires with it.

Key takeaways

ABAC evaluates attributes of subject, resource, and context against policy rules.
It handles context-dependent access better than RBAC but is harder to audit.
Cloud OIDC trust policies use ABAC-style conditions to scope pipeline access.