secrets-engine/workplans/SECRETS-WP-0009-glas-claude-native-delivery.md
tegwick b9058c96b2
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
docs: answer the GLAS-WP-0015 tenant question and record the DNS hazard
Probing the handed-over Service DNS name from the workstation found that
every *.svc.cluster.local name resolves here to one unrelated public
address via the ad.binect.de search suffix -- including names of services
that do not exist, which proves it is suffix expansion and not a record.

Pointing SECRETS_ENGINE_PDP_URL at the Service name would send the
CheckRequest body (subject, tenant, lane ids, stage, field names, purpose)
and the static Bearer token to that host. Decision envelopes are
structurally validated but not signed, so a responder knowing the package
and version can return a well-formed allow; the fail-closed posture
assumes the PDP is the PDP.

Not mitigated here: choosing the transport control is the owners' call,
not this consumer's. Recommended to FLEX-WP-0021-T05 that the handover be
a trailing-dot FQDN or explicit address, with the response channel's
authentication stated. Our pin stays unset, so the hazard is theoretical.

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
2026-09-06 22:34:20 +02:00

107 lines
5.2 KiB
Markdown

---
id: SECRETS-WP-0009
type: workplan
title: "Activate native Claude credential delivery for Glas"
domain: infotech
repo: secrets-engine
status: blocked
owner: codex
created: "2026-09-05"
updated: "2026-09-05"
state_hub_workstream_id: "40ccc3b4-d046-5a58-8649-e7935f45c974"
---
Demand: GLAS-WP-0012-T02 / SAND-WP-0015-T04, custody CCR-2026-0016.
The user authorized continuing credential delivery after storing the key in Bao.
This record tracks native read-lane adoption, not a new provider key or rotation.
## Define the exact native read lane
```task
id: SECRETS-WP-0009-T01
status: done
priority: high
state_hub_task_id: "4f1cf242-3aec-56a8-b958-5d53823875e0"
```
Added catalog glas-claude-agent-dev-anthropic; plan checks existing platform
mount and proposes one data-only read policy/AppRole. Token TTL5m/max15m,
single-use SecretID5m, token use budget8. See docs/glas-claude-delivery.md.
No metadata, sibling, listing or write capability is proposed.
## Support data-only delivery policies
```task
id: SECRETS-WP-0009-T02
status: done
priority: high
state_hub_task_id: "fa4a3e87-0854-5e2b-af44-facd5b25f443"
```
Added boolean delivery_auth.metadata_read with compatible default true and
explicit false for this lane. Validation refuses non-booleans; generated plan
omits metadata permissions when disabled. Full owner suite passes. Sand-boxer
synthetic exec-env transport proof passed; no real secret was read.
## Activate the approved native lane and verify real owner delivery
```task
id: SECRETS-WP-0009-T03
status: wait
priority: high
state_hub_task_id: "f8069c8a-ad6b-5d0b-9a36-c2326699437d"
```
Inbound 2026-09-06 (glas-harness `GLAS-WP-0015` production dependency handoff).
Ownership acknowledged. Answering their tenant question rather than assuming the
values lined up found a blocking defect in this repo, so the handoff earned its
keep before any activation work started.
- **Our CheckRequest carried no `tenant` at all.** The deployed
`secrets-engine.catalog-lane.lifecycle` **v2** package reads
`request_tenant := object.get(input, "tenant", "")` against
`known_tenant := "tenant:platform"`, so an absent tenant is a `wrong_tenant`
denial rather than an ignored field. Every gated action this engine sent would
have been denied, and the omission also produced a `request_digest` matching no
correctly issued decision, because `tenant` is hashed material. Fixed in
`80eafaf`; `REQUEST_TENANT` is pinned against the vendored allow envelopes.
- **The package is v2, not the v1 glas reported.** v1 had no tenant rule and
failed open — a `rotate` under `tenant:coulomb` returned allow against the
deployed package (`decision:066e629bbf0c0924`). flex-auth superseded rather
than amended it, because a fail-open correction must be visible as a version
change. Our accepted version moved to v2 and a test refuses a v1 decision.
- **Wrong-tenant denial evidence delivered**, from flex-auth's real deny envelope
rather than asserted: `decision:7d56b7fc274ddfd6`, `matched_rule wrong_tenant`,
`binding.tenant tenant:coulomb`. Vendored with tests that we refuse it on
`effect` first and that a deny legally carries no `lifetime`.
- **Tenant mapping NOT resolved, deliberately.** `service_auth.TENANT` is
`tenant:coulomb`, which is exactly the value the package denies. Either those
are two layers sharing a namespace format or one constant is wrong. Choosing
without an owner ruling is the fail-open shape `GH-DEC-2026-008` rejected for
action vocabularies. Both constants stay as they are, not unified behind one
symbol. Recorded in `docs/tenant-alignment.md` for `KEY-WP-0013-T02` /
`APPROVAL-WP-0002-T01`.
- **Hazard found while probing the caller access path.** Every
`*.svc.cluster.local` name resolves on this workstation to one unrelated public
address via the `ad.binect.de` search suffix, including names of services that
do not exist. Pointing `SECRETS_ENGINE_PDP_URL` at the Service name would ship
CheckRequest metadata and the Bearer token to that host, and decision
envelopes are structurally validated but not signed, so a knowing responder
could return a well-formed allow. Reported to flex-auth for `FLEX-WP-0021-T05`;
not mitigated here because the transport control is the owners' call. The pin
stays unset, so the hazard is theoretical today.
CCR-2026-0016 is explicitly treated as custody provenance, not a per-action
authorization. No unsafe-demo switch and no human runtime token will be used to
reach a prod lane. This task stays `wait`: activation is blocked on the owner
access path, not on engine work or on approval shape.
Depends on SECRETS-WP-0007-T04 and SECRETS-WP-0008-T02/T06: canonical production
authorization, successful consume and scoped service authority must exist.
Current production exec refuses before OpenBao because durable access-engine
decision records are not served. Do not bypass this with unsafe-demo or a human
operator runtime token. Then apply the exact read policy/AppRole, prove positive
and negative access, register delivery-ready evidence, bind owner exec with
service authentication, and return verified pins/evidence to SAND-WP-0015 and
GLAS-WP-0012. Provider scope/budget and expiry remain explicit acceptance inputs.
Keep the catalog route inactive until real verification passes.