tegwick
03c0569820
Adoption asked for by flex-auth (FLEX-WP-0021-T05) and glas-harness (GLAS-WP-0015), plus the first real decision this engine has obtained from the deployed pin -- which found a defect the fixtures could not. ACCESS PATH. require_supported_pdp_address refuses in-cluster Service names and any non-loopback host. This is no longer a unilateral call: the owner path is documented as loopback kubectl port-forward over the authenticated Kubernetes API, which is what authenticates the responder transitively (FLEX-DEC-2026-010). A Service name from a workstation does not fail, it resolves through the DNS search suffix to an unrelated public host, and since decision records carry no signature, a responder knowing the published package and version can return an allow that passes every check we make. Fail-closed protects against a PDP that is absent, not one that lies. The guard runs before the token is read, so a misdirected request cannot leak it; a test pins that ordering. LIVE PROOF. Minted a 10-minute TokenRequest token (audience flex-auth, SA secrets-engine/secrets-engine, mode 0600 outside the worktree, shredded after), forwarded to the named pod, and sent a real CheckRequest for glas-claude-agent-dev-anthropic. Result: allow, catalog_lane_policy_matched, served by v2 (sha256:bd11c5fe...) -- so the redeploy flex-auth flagged as outstanding has landed and the pin no longer serves the tenant-blind v1. Our tenant fix is confirmed against the real service: binding.tenant is tenant:platform. THE DEFECT IT FOUND. The evaluator enriches from its registry before hashing -- subject gains attributes and tenant, resource gains tenant -- so binding.request_digest is over material we never sent and cannot reproduce. validate_decision_envelope rejects every real allow. Every replay test passes because _request_from() rebuilds the request out of the binding, i.e. the enriched form: a self-consistent fake agreeing with itself, which hid this through three rounds of digest work. Third time a real artifact has beaten a fake in this integration. NOT FIXED, DELIBERATELY. Rejecting a valid allow is wrong in the safe direction. Which fields may be enriched is flex-auth's contract to publish; inferring it means accepting a binding that differs from our proposal in a way we decided was benign -- the fail-open shape GH-DEC-2026-008 rejected for vocabularies and FLEX-DEC-2026-007 for digests. Raised with them. Tenant question closed by operator decision 5ed3fb35: tenant:platform exactly, and service_auth.TENANT stays tenant:coulomb because the two identity layers are to remain distinct. Declining to author that mapping was right -- the answer was neither reading offered. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E4tNMAYcSQmZWUE4wqP4ij Assistant: claude-code Assistant-Model: opus Assistant-Process: 715726@bnt-lap001 Assistant-Session: 80a42b32-cba6-4b23-8be0-68819b1a6092
31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
# Live decision from the deployed pin
|
|
|
|
Not a vendored example. This is a real `DecisionEnvelope` this engine obtained
|
|
on 2026-09-07 from the deployed `flex-auth-secrets-engine` pin, through the
|
|
owner-documented access path:
|
|
|
|
- loopback `kubectl port-forward` to the named pod
|
|
`flex-auth-secrets-engine-65c74d4858-qvf2p`, over the authenticated
|
|
Kubernetes API (`FLEX-DEC-2026-010`: this is what authenticates the
|
|
*responder*);
|
|
- a 10-minute `TokenRequest` token for ServiceAccount
|
|
`secrets-engine/secrets-engine`, audience `flex-auth`, in a mode-0600 file
|
|
outside the worktree, shredded after use;
|
|
- request built by `build_action_request` for the real catalog lane
|
|
`glas-claude-agent-dev-anthropic`, action `rotate`.
|
|
|
|
The decision is `allow`, `catalog_lane_policy_matched`, served by
|
|
`secrets-engine.catalog-lane.lifecycle` **v2**
|
|
(`sha256:bd11c5fe…`) — so the redeploy flex-auth flagged as outstanding has
|
|
landed and the pin no longer serves the tenant-blind v1.
|
|
|
|
It contains no secret material: subject and resource metadata, digests, and
|
|
policy provenance only.
|
|
|
|
**Why it is kept.** It is the artifact that proved the digest join does not hold
|
|
against a real request. The evaluator enriches `subject` (attributes, tenant)
|
|
and `resource` (tenant) from its registry before hashing, so
|
|
`binding.request_digest` cannot equal a digest computed over the unenriched
|
|
request we sent. Every replay fixture test passes because `_request_from()`
|
|
rebuilds the request *from the binding*, which is the enriched form — a
|
|
self-consistent fake agreeing with itself. Only a real request exposed it.
|