ADR-0006: enforcement is zone-scoped; defer the policy.enabled flip
flex-auth enforced its ops-warden pin (FLEX-WP-0016 T03) and the gate verified clean against it: readiness exits 0, decision:f3f7c88f9585582a, anonymous /v1/check now 401. Everything needed to set policy.enabled: true was in place. It stays false, by decision. policy.enabled is a single repo-wide boolean, and with fail_closed: true it makes flex-auth a hard dependency of every warden sign — including the certs the ops-bridge tunnels depend on, one of which carries the policy call itself. Uniform enforcement across an estate being actively rebuilt hardens the access needed to perform the rebuild. The repo already refuses one-dimensional posture: WP-0015 shipped environment and maturity axes, WP-0029 added organization_posture. A global flag ignores all three. ADR-0006 records that enforcement belongs to a zone, and binds future work — a zone-blind enforcement flag is out of order, not merely unwise. WARDEN-WP-0032 drafts the zone model, leading with the ownership question: whether this is ops-warden's to own or NetKingdom canon to consume (ADR-0005). WP-0031 is finished with T05 cancelled and resuming as WP-0032-T05. Also replaces the hand-run kubectl port-forward with a managed ops-bridge tunnel, flex-auth-ops-warden-railiance01 (-L 19090:10.43.1.165:8080). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
parent
661176e37a
commit
cbf6828061
7 changed files with 273 additions and 9 deletions
101
docs/adr/ADR-0006-enforcement-is-zone-scoped.md
Normal file
101
docs/adr/ADR-0006-enforcement-is-zone-scoped.md
Normal file
|
|
@ -0,0 +1,101 @@
|
|||
---
|
||||
id: ops-warden-adr-0006
|
||||
type: adr
|
||||
title: "ADR-0006 — Enforcement is zone-scoped, never a global flag"
|
||||
domain: infotech
|
||||
repo: ops-warden
|
||||
status: accepted
|
||||
version: "1.0"
|
||||
revision: "1"
|
||||
owner: ops-warden
|
||||
binds: "ops-warden"
|
||||
created: "2026-08-19"
|
||||
updated: "2026-08-19"
|
||||
last_reviewed: "2026-08-19"
|
||||
review_interval: 6m
|
||||
enforced_by: "warden.yaml policy.enabled; scripts/check_policy_caller_identity.py; WARDEN-WP-0032"
|
||||
supersedes: ""
|
||||
successor: ""
|
||||
---
|
||||
|
||||
# ADR-0006 — Enforcement is zone-scoped, never a global flag
|
||||
|
||||
## Status
|
||||
|
||||
Accepted 2026-08-19, at the moment `policy.enabled: true` was ready to be set
|
||||
and deliberately was not.
|
||||
|
||||
## Context
|
||||
|
||||
WARDEN-WP-0031 finished the calling side of the flex-auth pre-sign gate. The
|
||||
flex-auth pin `flex-auth-ops-warden` runs `callerAuth.mode: enforce`; ops-warden
|
||||
presents a bound ServiceAccount token; the readiness gate exits 0 against the
|
||||
enforcing pin and an anonymous `/v1/check` is 401. Everything needed to set
|
||||
`policy.enabled: true` was in place.
|
||||
|
||||
`policy.enabled` is a **single boolean over the whole repo**. Combined with
|
||||
`fail_closed: true` it makes flex-auth a hard dependency of *every* `warden
|
||||
sign` — including the certificates the ops-bridge tunnels depend on, one of
|
||||
which is the tunnel carrying the policy call itself. A dead tunnel or a
|
||||
recreated Service does not degrade signing; it stops it.
|
||||
|
||||
That cost might be acceptable for a settled production lane. It is not
|
||||
acceptable uniformly, because ops-warden signs across an estate that is being
|
||||
actively rebuilt. During deep refactors — CoulombCore's decommission, the
|
||||
issue-core move, cluster rebuilds — the same flag would harden exactly the
|
||||
access needed to *perform* the refactor. Security that stops the work stops
|
||||
being security and starts being an outage with good intentions.
|
||||
|
||||
The repo already refuses to treat posture as one-dimensional. WP-0015 shipped
|
||||
environment posture (`dev` / `test` / `prod`) and workload maturity (`M0`–`M3`);
|
||||
WP-0029 added `organization_posture: build` as a third axis precisely because
|
||||
the *organization's* state changes what is reasonable to demand. A global
|
||||
`policy.enabled` contradicts all of that: it is a fourth control that ignores
|
||||
the three axes already declared.
|
||||
|
||||
## Decision
|
||||
|
||||
**Enforcement posture is a property of a zone, not of the repo.** ops-warden
|
||||
does not enable a fail-closed authorization gate globally. Before
|
||||
`policy.enabled: true` is set anywhere, the zones must exist: named bands of
|
||||
differing rigidity, each declaring what is enforced, what is advisory, and what
|
||||
is exempt — and the gate must be scoped to them.
|
||||
|
||||
Concretely, until WARDEN-WP-0032 defines the zone model:
|
||||
|
||||
- `policy.enabled` stays `false`. Its readiness is evidence, not a mandate.
|
||||
- A gate that is *ready* is recorded as ready. Readiness is not a reason to
|
||||
enable; deferral with a stated reason is a legitimate terminal state for a
|
||||
task, not an unfinished one.
|
||||
- Any future enforcement control ships zone-aware or does not ship. A second
|
||||
global boolean is the defect this record exists to prevent.
|
||||
|
||||
## Consequences
|
||||
|
||||
**We accept** that the pre-sign gate remains unexercised in production longer,
|
||||
and that the WP-0031 evidence ages. Re-running
|
||||
`scripts/check_policy_caller_identity.py` re-establishes it cheaply, and the
|
||||
readiness gate exists precisely so this is a re-check rather than a re-do.
|
||||
|
||||
**We accept** that flex-auth's `flex-auth-ops-warden` pin sits enforcing with no
|
||||
enforcing consumer. That is not waste: it makes the anonymous path 401 rather
|
||||
than a decision, which was the ADHOC-2026-08-17-T01 condition regardless of
|
||||
whether ops-warden calls it.
|
||||
|
||||
**We reject** the framing that a ready control should be turned on because it is
|
||||
ready. The question is not "does it work" but "which zone is this, and does this
|
||||
zone want this failure mode."
|
||||
|
||||
**This binds future work.** A zone-blind enforcement flag proposed in any
|
||||
ops-warden workplan is out of order under this ADR, and should be sent back to
|
||||
the zone model rather than merged with a caveat in its description.
|
||||
|
||||
## Related
|
||||
|
||||
- `WARDEN-WP-0031` — the calling side that made the flip possible (T05 deferred
|
||||
under this ADR)
|
||||
- `WARDEN-WP-0032` — the zone model this record defers to
|
||||
- `wiki/WorkloadSecurityPosture.md` — the two axes already shipped (WP-0015)
|
||||
- `wiki/PolicyGatedSigning.md` — the gate itself
|
||||
- `history/2026-08-19-flex-auth-caller-identity-evidence.md` — readiness evidence
|
||||
- flex-auth `FLEX-WP-0016` — the enforcing pin
|
||||
|
|
@ -67,3 +67,4 @@ and the publication is a defect.
|
|||
| `ADR-0003` | Cover gaps, but never silently own them | ops-warden |
|
||||
| `ADR-0004` | High-risk lanes refuse raw value streaming to agent sessions | ops-warden, and any agent runtime calling `warden access` |
|
||||
| `ADR-0005` | Implement one lane narrowly, route everything else | ops-warden |
|
||||
| `ADR-0006` | Enforcement is zone-scoped, never a global flag | ops-warden |
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue