tegwick
0bc624ba62
secrets-engine's first live request rejected our allow: binding. request_digest is computed over material they never sent, because we enrich subject and resource from the registry before hashing. Answering that meant reading the enrichment path, which had a worse defect in it. Enrichment was additive-if-absent — addAttribute wrote a registry value only where the request had no value for that key. So where a caller supplied a key, the caller's value won and the registry's never applied. Every registry ceiling and allowlist was advisory. Verified against the shipped ops-warden package, each one added key on an otherwise-denied request: max_ttl_hours: 99 registry says 8 -> allowed a 12h certificate allowed_principals registry allowlist -> disallowed_principal bypassed allowed_subjects registry allowlist -> unknown_subject bypassed The third is the one to read twice: a subject the registry does not know authorized itself by naming itself in the allowlist it was being checked against. Not remotely reachable today — the PEP builds the CheckRequest, ops-warden sends no resource.attributes, and enforce admits one identity. It is a defence-in-depth failure: any path that lets attacker-influenced data into a CheckRequest field became a full policy bypass rather than a bounded input problem. Callers sending resource.attributes is not hypothetical; secrets-engine does it on every request. Registry facts now win, and diagnostics.registry_overrode names every displaced key, because a registry that silently discards a contradicting claim hides that a caller asserted authority it did not have. subject.type is carved out, and the reason is a finding of its own. Making the registry win there denied every secrets-engine allow: the registry's type is CARING vocabulary (Human, Agent, Automation, Service) and the request's is the protected system's actor vocabulary (service, adm, agt, atm). Two fields sharing a name; substituting one for the other is translation rather than identity, which GH-DEC-2026-008 ruled against. Note what surfaced it — the registry's type had been dead data since the field existed, because the caller's value always won. Also publishes binding.submitted_request_digest, over the request exactly as sent. request_digest was published as the consumer replay test and cannot be one. Nothing is lost hashing the pre-enrichment form: enrichment is a function of the request and the snapshot, and registry_snapshot_digest already pins the snapshot. Existing pins do not move. All three replay fixtures' request_digest and approval_binding_digest values are byte-identical — those requests contradict no registry fact. A field to add, not a value to correct. Regression tests verified failing against the old behaviour before being kept. FLEX-DEC-2026-012; FLEX-WP-0025 carries the residual, that a policy still cannot tell a fact from an assertion. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014aQMM1dPXaPiXVn6DwwtLd Assistant: claude-code Assistant-Model: opus Assistant-Process: 715613@bnt-lap001 Assistant-Session: fabd95c1-4c9e-4080-8849-8707ae025f80 |
||
|---|---|---|
| .. | ||
| replay | ||
| check_request_allow_destroy_dual_control.json | ||
| check_request_allow_rotate.json | ||
| check_request_deny_destroy_without_claim.json | ||
| check_request_deny_revoke_not_an_action.json | ||
| check_request_deny_unknown_subject.json | ||
| check_request_deny_wrong_tenant.json | ||
| policy_fixtures.yaml | ||
| policy_package.md | ||
| protected_system_manifest.yaml | ||
| README.md | ||
| registry_snapshot.json | ||
| subject_manifest.yaml | ||
secrets-engine example
Policy package, manifests, and fixtures for secrets-engine's gated
catalog-lane operations. Opened by FLEX-DEC-2026-005, carried by
FLEX-WP-0021.
| File | What it is |
|---|---|
policy_package.md |
secrets-engine.catalog-lane.lifecycle v2, allow_ttl: 15m |
protected_system_manifest.yaml |
the secret-catalog-lane resource type and twelve actions |
subject_manifest.yaml |
the single secrets-engine service identity |
registry_snapshot.json |
loadable snapshot combining both manifests |
policy_fixtures.yaml |
32 fixtures — 11 allows, dual control both ways, and every denial branch |
check_request_*.json |
standalone requests for POST /v1/check |
The action vocabulary is secrets-engine's, delivered under
FLEX-WP-0021-T01 and recorded in
../../docs/secrets-engine-action-vocabulary.md.
Read that before changing any action string here.
Verify
go run ./cmd/flex-auth validate -kind policy -file examples/secrets-engine/policy_package.md
go run ./cmd/flex-auth load-registry -file examples/secrets-engine/registry_snapshot.json
28 Rego tests and 32 fixtures.
Deployed, and the version to pin
FLEX-WP-0021-T04 deployed the flex-auth-secrets-engine pin on 2026-09-06:
Service: http://flex-auth-secrets-engine.flex-auth.svc.cluster.local.:8080
^ trailing dot, required
Package: secrets-engine.catalog-lane.lifecycle
Version: v2
callerAuth.mode: warn (not enforced caller authentication)
The trailing dot is not cosmetic, and this address is in-cluster only.
secrets-engine reported and flex-auth reproduced that on the workstation a
bare *.svc.cluster.local name resolves through search ad.binect.de to one
unrelated public host — a name for a service that does not exist resolves to the
same address, which proves it is suffix expansion rather than a record. The
trailing-dot form correctly fails to resolve instead. A bare Service name in a
handover is therefore not merely unreachable from a workstation, it is a live
misdirection. See ../../docs/operator-caller-access-path.md.
Ingress admits namespace secrets-engine with pod label
app.kubernetes.io/name=secrets-engine and default-denies everything else. A
workstation CLI process is not that, and Service DNS is not workstation
connectivity — an operator-run consumer needs a decided access path before it
can call this pin at all (FLEX-WP-0021-T04's three shapes).
Pin _VERSION to v2, never v1. v1 is deployed and superseded: it had
no tenant rule and allowed a foreign tenant. See the correction section in
policy_package.md. The pin still serves v1 until the redeploy lands, which
is why the version is stated here rather than left to be read off the running
service.
SECRETS_ENGINE_AUTHORIZATION_POLICY_PACKAGE / _VERSION remain fallback-free
and fail-closed by design; nothing here changes that.