Learning outcomes
- Place policy administration, information, decision, enforcement, distribution, and evidence responsibilities.
- Define trust, freshness, availability, and failure behavior for each connection.
- Detect bypass paths and components that combine conflicting authority.
- Produce evidence that connects policy intent to enforced action.
System and boundaries
Use responsibilities before product names:
- The policy administration point creates, reviews, approves, and publishes policy.
- Policy information sources provide identity, resource, device, threat, time, and environment facts.
- The policy decision point evaluates a request against policy and inputs.
- The policy enforcement point intercepts the protected action and applies the result.
- Distribution moves policy and trusted context to consumers.
- Evidence records administration, input freshness, decision, and enforcement.
One service can hold several responsibilities, or one responsibility can be distributed. The trust analysis still needs each boundary.
Request and decision flow
Start with a subject, resource, action, and context. The enforcement point intercepts the request and constructs or forwards the decision tuple. The decision point obtains policy and authorized inputs, evaluates them, and returns an explicit result and reason. The enforcement point maps that result to a safe action. Evidence connects the request, policy revision, input versions, result, and enforcement.
Trace the administration path separately. A reviewed source becomes a compiled or distributed policy, reaches each evaluator, and activates at a known version.
Failure domains
- The enforcer fails to intercept an alternate protocol or origin path.
- The decision point cannot distinguish missing context from a negative value.
- An input source is compromised or stale.
- A policy distribution delay leaves evaluators on different versions.
- The enforcer maps indeterminate or timeout to allow.
- An administrator can author, approve, and conceal a sensitive change.
- Evidence records a decision but not whether it was enforced.
Design tradeoffs and residual risk
Central decisions can improve consistency and explanation but add latency and shared failure. Local decisions reduce dependency but increase distribution and version drift. Rich inputs improve precision but add collection, privacy, integrity, and availability costs. Cached results improve availability but create stale-access windows.
Assign safe behavior for every dependency failure. State maximum age, rollback, and evidence requirements before choosing where to cache.
Pomerium boundary
Pomerium can act as a decision and enforcement layer for protected routes. Its policy can use identity, request, device, and external context. The identity provider and external data sources remain separate authorities. The upstream application remains the decision and enforcement owner for its internal objects and actions.
Exercise
Map one protected application. Draw the administration path and one request path. Label every component with its owner, trusted inputs, authenticated channel, cache, maximum age, failure result, and evidence.
Remove the policy information source and decision service in separate tests. Confirm that the observed result matches the stated safe behavior.
Evaluation checklist
- Can every policy, input, decision, and enforcement responsibility be identified?
- Does the enforcement point intercept every path to the protected action?
- Are input authority, integrity, age, and absence semantics explicit?
- Do all errors, conflicts, and timeouts map to a safe result?
- Can evidence prove which policy and inputs the enforcer used?
Next learning unit
Policy as Code
Treat access policy as a versioned, reviewed, tested, and observable decision artifact with controlled deployment.
