RBAC, ABAC and least privilege: decide who can change what
Compare role-based and attribute-based access control with a deployment example. Learn why permission scope, trusted attributes and negative tests determine least privilege.
TL;DR: RBAC grants permissions through roles; ABAC evaluates attributes of the subject, resource, action and context. Either can implement excessive privilege. Define the allowed operation first, then test both the expected allow and the nearby denials.
Start with a concrete permission
“Developers can deploy” leaves important questions unanswered. Which environment, which application, which artifact, and through which identity? For a fictional payments service, a narrower requirement is: its deployment job may update the staging workload using an approved artifact; the same job may not change production policy or read another team's secrets.
With role-based access control, assign the job a role containing those permitted operations over the intended scope. With attribute-based access control, a policy might require the principal's team to match the resource's owning team and the requested environment to be staging. NIST's ABAC definition includes subject, object, operation and environmental attributes. These are models for an authorization decision, not competing ways to authenticate a login.
The diagram allows roles and attributes to participate together. Many practical systems combine them: a role defines the action family, while conditions narrow its resource or execution context.
Compare policies using the same requests
| Request from the staging deploy job | Intended outcome | Reason |
|---|---|---|
| Update payments staging workload | Allow | Matching owner, environment and permitted action |
| Update payments production workload | Deny | Environment exceeds the grant |
| Read payroll's database secret | Deny | Different owner and wrong action |
| Change its own team attribute | Deny | Would let the subject rewrite the authorization input |
The last row is easy to omit. If a principal can retag itself or a resource to satisfy a policy, the apparent restriction can become self-service privilege escalation. Attribute integrity includes who writes the value, how identity claims are mapped, and what happens when an attribute is missing.
AWS's ABAC guidance describes matching principal and resource tags. Actual support varies by service and action, so check the applicable condition keys rather than assuming a tag rule controls every API. Decide how to authorize resource creation, when the resource does not yet have an existing tag, and how later tag changes are controlled.
Roles can grow faster than the organization
Imagine four teams, three environments and two operational responsibilities. Creating one role for every combination gives 24 role variants before exceptions. That number is illustrative, not an argument that 24 roles are inherently unmanageable. Explicit roles can be easy to review when the organization is small and changes slowly.
ABAC can reduce repeated policy definitions, but transfers complexity into attribute governance. A single incorrect team claim can affect many resources simultaneously. For a small production boundary, I would keep an explicit scoped deployment role and use trusted attributes only where they remove proven duplication. Adopt broader ABAC when the identity and resource inventories have owners and reliable lifecycle controls.
Kubernetes illustrates why implementation details matter. Its RBAC permissions are additive; a RoleBinding with fewer permissions does not subtract permissions already granted elsewhere. Native RBAC also does not become general label-based ABAC merely because objects carry labels. Use the platform's actual authorization and admission mechanisms rather than importing another provider's semantics.
Test the effective authority
A policy review should follow all grants available to the identity, including group membership, inherited bindings and resource policies where the platform supports them. Restricting one policy can leave a second broad grant intact. For cloud-specific allow/deny precedence, use IAM policy evaluation; there is no universal precedence rule shared by every RBAC and ABAC engine.
Construct a small request matrix before rollout. Include the valid operation, a neighboring team's resource, a forbidden environment, missing attributes, and an attempt to alter the attributes themselves. Run policy simulation where available, then verify representative authorized operations in an isolated environment. Simulation does not prove every runtime context or resource policy was supplied correctly.
An interviewer may ask how to keep least privilege from decaying. Review actual usage alongside the intended job: unused authority is a removal candidate, but infrequent disaster-recovery permissions require an explicit operational decision. Separate routine jobs from time-bounded emergency elevation and make the latter observable. Removing a permission because it was unused last week can break a yearly recovery exercise.
Self-check: an engineer has a narrow staging role plus membership in a group with cluster-wide administrative privileges. Does the narrow role limit their effective access? In an additive model such as Kubernetes RBAC, no. Review and change the broad grant or separate the identities. A smaller role attached alongside an administrator grant is documentation, not an enforced boundary.