Tag-based access: defend the attribute write path

Last updated: 5 Oct 20266 min read

tutorial

Attribute-based access compares principal, request, and resource attributes to decide whether an operation is allowed. If a caller can change a resource's authorization tag or supply an untrusted session tag, it may grant itself access without editing an obvious identity policy. Tag conditions also vary by API operation and resource type; a condition that works on reads may not cover creation, tagging, or deletion. The system must control how trusted attributes enter and change.

Operational decision

A ledger team uses a project tag to isolate payout reports. The session's project value comes from a trusted identity source, while only a separate platform role can change the protected project tag on a report store. At resource creation, require the project tag to match the caller's trusted project and reject absent or extra authorization tags. At update, deny changes to the protected key even when ordinary descriptive tags may be edited. Test a caller who tries to retag another team's resource, remove the tag, create a resource without a tag, and pass a forged session value. Check every API action in the intended workflow for tag-condition support and for operations that authorize against parent resources rather than the new object. Keep cost-center and display-name tags separate from access-control tags so routine accounting edits cannot change access. If a federated identity maps a human attribute to a session tag, review both the mapping and who can alter the upstream attribute. A successful same-team read is only half the test; cross-team denial and mutation denial are the more valuable evidence.

Payout report ABAC test matrix
Trusted session project: ledger-west
Own report: read allowed
Other-project report: read denied
Create without project tag: denied
Retag other report to ledger-west: denied
Remove protected project tag: denied
Change descriptive owner note: permitted by separate rule

Cost and verification

Testing A protected actions against T attribute states takes O(A × T) cases if every combination is exercised. The policy can be small, but the attribute supply chain and service-specific condition support increase review cost. Measure authorization-tag mutations, resources missing trusted tags, cross-project negative-test results, and denied legitimate creates. A tag-based model that cannot explain who sets the tag is incomplete.

Common Mistakes

Do not trust a session tag merely because it appears in the request.
Do not allow routine tag editors to alter authorization attributes.
Do not assume a tag condition applies to every service operation.

Connected lessons

Practice and check

devops

cloud-security