Learning outcomes
- Distinguish discretionary, mandatory, role-based, and attribute-based policy authority.
- Select a model from resource ownership, administration, context, and assurance needs.
- Identify unsafe delegation, role growth, label errors, and attribute drift.
- Combine models without hiding conflict and precedence.
Protection need
The policy model must express who controls access, which resource and action it protects, and which facts can change the result. Discretionary Access Control lets an owner grant authority. Mandatory Access Control applies centrally defined labels and rules that owners cannot override. Role-Based Access Control assigns permissions through roles. Attribute-Based Access Control evaluates attributes of subjects, resources, actions, and environment.
Security objectives and requirements
Use Discretionary Access Control when accountable owners can delegate without violating central constraints. Use Mandatory Access Control when classification and information-flow rules must override owner preference. Use roles for stable job functions and separation of duties. Use attributes for resource, action, tenant, device, time, and other dynamic context.
Name the administration model, authoritative data, default result, conflict rule, lifecycle, and evidence. A system can combine models, such as a mandatory tenant boundary plus roles and current device context.
Security invariants and evidence
No owner can grant around a mandatory rule. Roles do not accumulate after a job change. Attributes come from accountable sources and remain fresh enough. The final policy names the exact resource and action. Decision evidence shows the effective model, inputs, result, and reason.
Failure cases
- Owner delegation leaks data across a mandatory tenant boundary.
- Roles grow into broad standing privilege and obsolete assignments remain.
- An attribute name has different meaning across issuers.
- Policy conflict allows access because no explicit combining rule exists.
- A route-level model is assumed to cover application objects.
Design tradeoffs and residual risk
Simple owner lists are easy to understand and hard to govern at scale. Roles reduce repeated assignments and can hide overbroad permissions. Attributes express context and add authority, freshness, and policy complexity. Mandatory labels provide strong central constraints and can obstruct legitimate collaboration.
Residual risk includes incorrect ownership, stale lifecycle, label errors, compromised attribute sources, and hidden policy layers.
Pomerium boundary
Pomerium route policy can express identity and context criteria. Operators define attribute authorities, lifecycle, conflict semantics, and resource scope. Applications still enforce their own object-level ownership, roles, labels, and actions.
Exercise
Model one document administration service four ways. For each model, identify who can grant access, how a mover loses access, which tenant boundary cannot be overridden, and how a current device requirement applies. Add a conflict and prove the expected result.
Evaluation checklist
- Who controls policy in each model?
- Which model protects resource, action, ownership, classification, role, and context needs?
- Are lifecycle, authority, freshness, and conflict explicit?
- Can a discretionary grant or broad role bypass a mandatory boundary?
- Does application object authorization remain distinct from route policy?
Next learning unit
Access Control
Combine policy, reliable decision inputs, enforcement, and evidence to control actions on protected resources.
