Operate access configuration as code

Operating objective

The organization can identify the exact reviewed source that produced every effective route, policy, issuer, certificate, and trust setting. Only an approved delivery identity can change runtime state. Unapproved drift is detected, investigated, and safely reconciled.

Configuration as code includes source, reusable modules, generated output, secrets references, validation, review, build, artifact, deployment, runtime activation, and rollback. Source control alone does not protect the full path.

Signals and evidence

Record repository and revision, author and reviewers, signed or authenticated change, test results, generator and dependency versions, artifact digest, deployment identity, target environment, activation result, effective runtime digest, and rollback. Keep secrets outside source and generated logs.

Measure pending changes, failed validation, policy conflicts, stale environments, runtime drift, manual mutation, partial rollout, rejected versions, and emergency changes. Compare normalized effective configuration, not formatting.

Response and recovery

1. Define one authoritative source and ownership boundary.
2. Validate schema, references, identities, resources, routes, certificates, and no-overlap invariants.
3. Run positive and negative authorization tests, route collision tests, direct-origin checks, and dependency-failure cases.
4. Review semantic changes and generated output. Protect against a generator or dependency that changes meaning.
5. Build an immutable artifact and attach provenance or equivalent evidence.
6. Deploy with a narrow identity to a bounded target. Verify runtime activation and request behavior.
7. Compare source, artifact, and runtime digests. Alert on drift.
8. For drift, preserve evidence and determine whether the cause is emergency work, compromise, failed automation, or another owner. Reconcile deliberately.
9. Roll back to a known-good artifact. Do not regenerate an old revision with new dependencies and call it the same state.

Design tradeoffs and residual risk

Declarative reconciliation reduces manual drift and can erase legitimate emergency containment. Locking all manual changes improves consistency and can delay incident response. Provide a controlled emergency path that records, expires, and backports the change.

Reusable modules reduce repetition and increase shared blast radius. Generated policy can be consistent and hard for reviewers to understand. Show the effective semantic diff.

Residual risk includes compromised source control, CI, generator, artifact registry, deployment credential, or control plane. Runtime validation and decision evidence remain necessary.

Pomerium boundary

Pomerium consumes configuration according to its deployment mode and can expose effective behavior through routes, policy decisions, logs, and health. Operators own source control, generation, secret handling, review, delivery, drift detection, and rollback. Pomerium cannot prove that the repository was the only source of runtime change.

Exercise

Make one narrow policy change in staging. Capture source revision, semantic diff, tests, artifact digest, deployment identity, runtime digest, and request evidence. Then make a controlled out-of-band runtime change and confirm that drift detection finds it.

Run the emergency path to deny one compromised route. Preserve the change, backport it to source, expire the emergency authority, and verify that reconciliation keeps the intended deny.

Evaluation checklist

• Is one authoritative source connected to immutable artifacts and runtime state?
• Do tests cover semantics, conflicts, negative access, and failure behavior?
• Are generators, dependencies, artifacts, and deployment identities protected?
• Can drift be detected without destroying emergency containment?
• Does rollback use the exact known-good artifact and revoke bad authority?