Learning outcomes
- Separate policy administration, decision, information, and enforcement responsibilities.
- Trace configuration and request flows through their trust boundaries.
- Define state, identity, integrity, freshness, and failure rules for each component.
- Test that the enforced result matches the effective policy decision.
System and boundaries
The policy administrator turns approved policy and decisions into effective configuration, sessions, credentials, or commands. The policy engine or decision point evaluates a request. Policy information points supply identity, device, resource, threat, and other context. The policy enforcement point applies the result to the protected path. Repositories, deployment systems, identity providers, logs, and recovery controls complete the system.
Separate logical responsibility from process count. One process can contain several components. One component can be distributed across replicas. Draw trust boundaries for administrative identity, configuration delivery, request identity, context, decision, enforcement, evidence, and the protected resource.
Request and decision flow
- An authorized owner defines protection intent for a named resource and action.
- The administration path validates, reviews, versions, and distributes policy.
- A requester sends an action through the enforcement point.
- The enforcement path establishes subject, resource, action, and trusted request context.
- The decision point obtains required information and selects the effective policy.
- It returns a bounded decision and reason.
- The enforcement point applies the result to the same request and target.
- Independent target evidence confirms whether the action occurred.
Trace configuration and requests separately. A secure request path can still use policy changed through a weak control plane.
Failure domains
A compromised policy administrator can distribute broad access. A compromised decision point can allow requests or falsify reasons. A compromised information source can provide false or stale context. A bypassed enforcement point makes correct decisions irrelevant. A protected resource can accept a different identity or action after the gateway allows the route.
Define authenticated distribution, version acceptance, stale-state bounds, cache behavior, timeout results, replica disagreement, rollback, evidence gaps, and degraded operation. Test missing identity, stale context, policy unavailability, decision timeout, enforcement loss, and direct-origin access.
Design tradeoffs and residual risk
Central decisions improve consistency and create latency and availability dependency. Local decisions improve resilience and can use stale policy or context. Rich information improves precision and expands privacy, integrity, and dependency risks.
Combining components reduces operational complexity and joins their failure domains. Separating them limits some effects and adds communication boundaries. Residual risk includes compromised administrators, incomplete route coverage, inconsistent replicas, and application actions outside route policy.
Pomerium boundary
Pomerium separates authentication, authorization, and proxy responsibilities according to the deployment model. Its Authorization service evaluates configured policy, and its Proxy enforces the route result. Operators own policy administration, configuration delivery, context sources, upstream isolation, application authorization, deployment topology, and recovery.
Exercise
Draw one protected route with policy owner, repository, deployment identity, identity provider, context sources, Pomerium components, upstream, application authorization, logs, and recovery. Label each control-plane and data-plane trust boundary.
Run negative tests for a missing subject, wrong resource, stale context, unavailable information source, old policy version, decision timeout, direct origin, and application object action. Record which component must fail safely in each case.
Evaluation checklist
- Does each component have one clear decision, administration, information, or enforcement responsibility?
- Are configuration and request paths both authenticated, authorized, versioned, and observable?
- Can the enforcement result be tied to the exact decision and resource?
- Are stale state, timeout, replica disagreement, bypass, and recovery defined?
- Does independent target evidence confirm the final action?
Next learning unit
Control Plane and Data Plane
Separate the systems that define and distribute access policy from the request path that enforces it on live traffic.
