coulomb/flex-auth
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Review the stance register's second row; record why T04 cannot proceed
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 2s
Details

Browse source 
TWO FINDINGS, BOTH FROM READING OTHER REPOSITORIES RATHER THAN OURS.

The §13.1 stance register has a second row. secrets-engine published
pep-stance.yaml -- total over catalog stage plus unknown, runtime-read
and pinned to SHIPPED_STANCE by test. SCOPE.md claimed ops-warden's was
the estate's only published map and that the register's single row was
itself the finding; that is no longer true and is corrected.

docs/stance-register-review.md is the first exercise of the
aggregate-divergence capability flex-auth claimed on 2026-08-29 and then
recorded as unexercised because one row cannot diverge from anything.
Three findings:

The two maps take opposite stances on unknown -- ops-warden fail_open by
versioned build profile under ADR-0009, secrets-engine fail_closed. Both
conformant, neither a defect, and they disagree about the one case nobody
planned for. Reported as an observation for gate-house's register, not as
a request that either repository change: a PDP does not set a consumer's
stance, and §9.3's two-owner split is our own finding.

The rows are not comparable. ops-warden scopes by security-zone,
secrets-engine by catalog-stage. §6.4 permits both, but the register
cannot then answer what the estate's stance is for a z2 workload. Worth
recording before a third row arrives.

secrets-engine's map defines fail_closed in terms of a durable
ActionAuthorization record, which GH-DEC-2026-005 shelved. The stance is
unaffected -- only the artifact name is stale -- but the file is read at
runtime and pinned by test, so the stale name outlives a comment.

SEPARATELY, T04 IS BLOCKED AND THE REASON IS STRUCTURAL. The task assumed
the ops-warden/tenant-engine/user-engine pattern, where the pin's
default-deny NetworkPolicy admits one approved consumer workload.
secrets-engine has no Kubernetes deployment at all -- it is a CLI. There
is no pod selector to write, and inventing one would repeat the error
corrected in T02. Three possible shapes recorded in the workplan and
raised with them; callerAuth, not the NetworkPolicy, becomes the real
boundary if an operator CLI is the caller, so the FLEX-WP-0016 precedent
does not transfer unexamined.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JTbVXpEiXA7mNJVpDnEPcB

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 412054@bnt-lap001
Assistant-Session: 3968fae1-8d59-4209-9bd6-c22594b8ab19
This commit is contained in:
tegwick 2026-09-06 09:31:40 +02:00
parent 591df344fb
commit c3ede0b494
3 changed files with 133 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

23
workplans/FLEX-WP-0021-secrets-engine-consumer-policy-gate.md
View file

@ -178,6 +178,29 @@ Owner: `flex-auth`; deployment approval required.
Gate: the pin answers `POST /v1/check` for the secrets-engine workload and
default-denies every other source; the other two pins are unchanged.
**Blocked 2026-09-06 — the consumer is not a workload.** This task was written
from the `ops-warden` / `tenant-engine` / `user-engine` pattern, where the pin's
default-deny `NetworkPolicy` admits ingress from exactly one approved consumer
*workload*. `secrets-engine` has no Kubernetes deployment at all: it is a CLI
(`src/`, `cli.py`, `pyproject.toml`) with no manifests, no namespace, and no pod
labels. There is no selector to write, and inventing one would be the same error
corrected in `FLEX-WP-0021-T02` — authoring against a shape that does not exist.
Three shapes are possible and the choice is not flex-auth's alone:
1. **Operator-run CLI reaching an in-cluster pin.** Needs a decided ingress
path (tunnel or port-forward), and `callerAuth` becomes the real boundary
rather than the `NetworkPolicy`, because the source address is an operator's
machine rather than a pod.
2. **A `secrets-engine` workload that does not exist yet.** Then this task is
correct as written but waits on `secrets-engine` to have one.
3. **No pin at all**, if the gate is only ever consulted from an operator
context that already holds a decision.
Raised with `secrets-engine`; T04 does not proceed until the shape is decided.
Note this also changes what `callerAuth.mode: warn` is warning about, so the
`FLEX-WP-0016` precedent does not transfer unexamined.
## 5. Hand the pin coordinates back and close
```task