docs: prepare actionable production dependency handoffs
Assistant: codex Assistant-Model: gpt-6-astra Assistant-Session: 01a0726e-5232-73f2-aaca-2c05ceb62efb
This commit is contained in:
parent
4608f10632
commit
49c47a746a
3 changed files with 195 additions and 0 deletions
124
docs/production-dependency-handoffs.md
Normal file
124
docs/production-dependency-handoffs.md
Normal file
|
|
@ -0,0 +1,124 @@
|
|||
# Production dependency handoffs
|
||||
|
||||
Prepared 2026-09-06 from GLAS-WP-0012 and the deployed policy-service evidence.
|
||||
These are reviewable owner requests, not delivered messages or authority grants.
|
||||
Glas coordinates acceptance; each owner retains implementation and authorization.
|
||||
No credential values belong in responses.
|
||||
|
||||
## Ready infrastructure
|
||||
|
||||
FLEX-WP-0021-T04 deployed flex-auth-secrets-engine revision 1, available 1/1,
|
||||
with five policy fixtures and positive/negative network probes passing.
|
||||
Endpoint: http://flex-auth-secrets-engine.flex-auth.svc.cluster.local:8080.
|
||||
Package: secrets-engine.catalog-lane.lifecycle v1.
|
||||
Image: sha256:89086c02c74a931068423e70937d03df7850fa0db9c63e70be56b3558f1756af.
|
||||
Caller-auth is warn. Direct cluster ingress requires namespace secrets-engine
|
||||
and pod label app.kubernetes.io/name=secrets-engine. A workstation process needs
|
||||
an explicitly supported owner access path; Service DNS is not workstation
|
||||
connectivity. Do not turn warn into enforce before caller adoption is proved.
|
||||
|
||||
## 1. Tenant alignment — key-cape, approval-engine, secrets-engine, flex-auth
|
||||
|
||||
Before materializing credentials, reconcile three existing values:
|
||||
approval store `platform`, proposed client JWT `tenant:coulomb`, policy tenant
|
||||
`tenant:platform`. JWT/store comparison is exact. These may identify distinct
|
||||
layers, but an explicit owner-reviewed mapping is required; spelling similarity
|
||||
is not a valid mapping.
|
||||
|
||||
Return: the exact store tenant, JWT tenant, CheckRequest tenant and any permitted
|
||||
mapping, with a decision/contract reference and wrong-tenant denial evidence.
|
||||
No unilateral change to live clients or policy subjects is requested.
|
||||
Related: KEY-WP-0013-T02, APPROVAL-WP-0002-T01, SECRETS-WP-0009-T03.
|
||||
|
||||
## 2. Admit service-client custody — railiance-platform with key-cape
|
||||
|
||||
Use key-cape/docs/approval-engine-provisioning-request.yaml, not a new invented
|
||||
lane. After tenant alignment, admit these proposed exact coordinates:
|
||||
|
||||
| Client | OpenBao entry | Secret field | Kubernetes delivery |
|
||||
|---|---|---|---|
|
||||
| secrets-engine-approval | platform/workloads/secrets-engine/approval-client | client_secret | sso/keycape-secrets-engine-approval-client, key client-secret |
|
||||
| approval-engine-operator | platform/workloads/approval-engine/operator-client | client_secret | sso/keycape-approval-engine-operator-client, key client-secret |
|
||||
|
||||
Resolve first-provision authority through the custody owner. Do not bootstrap
|
||||
these via the very production lane whose authorization they enable. Record
|
||||
admission/CCR ids, field names, reader/writer scope, revocation and delivery
|
||||
receipts, never values. Supply protected delivery for KeyCape and the intended
|
||||
client process; a KeyCape-side Secret alone does not provision the consumer.
|
||||
|
||||
Return: admitted owner records, protected materialization and exact consumer
|
||||
bindings, plus negative sibling/read/write tests where applicable. Local
|
||||
KEY-WP-0013 source registration is not evidence of live provisioning.
|
||||
|
||||
## 3. Deploy and prove KeyCape clients — key-cape
|
||||
|
||||
KEY-WP-0013-T02: roll out resource-audience support and both registrations with
|
||||
the approved custody inputs. Live issuer is https://kc.coulomb.social; JWKS
|
||||
service is keycape.sso.svc.cluster.local:8080/jwks. Verify JWT signature,
|
||||
resource audience approval-engine, exact agreed tenant, subject, scopes,
|
||||
principal type and lifetime (15m), plus excessive-scope/wrong-secret denial.
|
||||
Preserve existing registrations and signing key.
|
||||
|
||||
Return immutable image and claim-contract proof references; no tokens. Identify
|
||||
whether missing human callback registration blocks this service-only phase or
|
||||
can remain separately tracked. Do not invent a human callback or relax MFA.
|
||||
|
||||
## 4. Register approval audit source — audit-core with railiance-platform
|
||||
|
||||
AUDIT-WP-0009-T09 / AUDIT-IN-0001 is now on the deployment critical path:
|
||||
approval-engine production startup requires audit delivery. Its task currently
|
||||
says low priority and "not blocking" because the producer is not emitting;
|
||||
please review that dependency against the concrete startup gate.
|
||||
|
||||
Register source/sender approval-engine, agreed tenancy, the four event classes,
|
||||
retention/access/export policy and load-bearing evidence handling. Provision
|
||||
its token by the approved custody path to approval-engine/approval-engine-audit
|
||||
key audit-token; add narrowly scoped receiver ingress and receiver config.
|
||||
Keep user-engine's sender unchanged.
|
||||
|
||||
Return: registration/custody references, accepted/duplicate and wrong-token
|
||||
proof, approved ingress, and the remaining cadence/reconciliation gates
|
||||
(AUDIT-WP-0009-T04/T06/T09). No sender token in the response.
|
||||
|
||||
## 5. Release approval-engine — approval-engine
|
||||
|
||||
APPROVAL-WP-0002-T03: build/scan an immutable image for current migrated schema,
|
||||
render corrected issuer/JWKS and agreed tenant, and validate deployment inputs.
|
||||
Image preparation can proceed before live credential materialization. Deploy
|
||||
only when identity and audit requirements pass; retain single-writer PVC and
|
||||
migration semantics. For first install record no prior DB; for replacement
|
||||
require verified backup. Prove readiness, restart persistence and restore.
|
||||
|
||||
Return deployed base URL, image digest, migration/storage/restart/restore and
|
||||
audit evidence. Existing manifest endpoint fixes at 06544b0 do not close T03.
|
||||
|
||||
## 6. Adopt authorization and activate lane — secrets-engine with flex-auth
|
||||
|
||||
SECRETS-WP-0009-T03 / FLEX-WP-0021-T05: consume the deployed policy coordinates
|
||||
above through a verified caller access path. Confirm exact package/image and
|
||||
CheckRequest/claim binding against the real service; adopt the caller identity
|
||||
before authentication enforcement. Configure the approval endpoint and per-lane
|
||||
authorization id only after the owner service and approval exist.
|
||||
|
||||
Then apply the exact data-only read policy/AppRole, verify positive and negative
|
||||
access and protected owner delivery for glas-claude-agent-dev-anthropic.
|
||||
Custody CCR-2026-0016 is not a per-action authorization. Do not use a human
|
||||
runtime token or unsafe-demo. Return activation and scoped delivery receipts.
|
||||
|
||||
## 7. Pin combined runtime — sand-boxer with rein-aharness
|
||||
|
||||
SAND-WP-0015-T04: pin Claude executable plus the rein Python artifact, prepare
|
||||
the exact combined sandbox profile and credential-route binding, and prove
|
||||
startup/private state/egress through the owner path Glas uses. Runtime work
|
||||
can proceed in parallel with identity/audit deployment.
|
||||
|
||||
Resolve the currently different project examples explicitly: the Glas real
|
||||
acceptance runner uses actor agt/project glas-local-proof; the owner delivery
|
||||
documentation example uses project glas-harness. Return the reviewed binding
|
||||
and adapt the fixture/config together; do not broaden the route to all projects.
|
||||
|
||||
Return: profile id/revision, host scope, runtime digest/executable paths, exact
|
||||
consumer tuple, declared egress and denial/cleanup evidence. GLAS-WP-0012 then
|
||||
reviews version 1.1.0, executes its real artifact proof and promotes only the
|
||||
proven candidate. Provider workspace scope and spend limit remain operator
|
||||
inputs; model budget_tokens does not establish a provider spend limit.
|
||||
|
|
@ -291,3 +291,14 @@ Approval-engine remains undeployed: live KeyCape clients and audit sender are
|
|||
absent, the tenant contract needs alignment, and a release digest is required.
|
||||
Corrected its stale issuer/JWKS deployment inputs. No production credential
|
||||
lane or real Claude run was activated; T02 remains wait.
|
||||
|
||||
## Production dependency coordination
|
||||
|
||||
GLAS-WP-0015 now tracks exact owner handoffs and return receipts from Glas.
|
||||
The requests in docs/production-dependency-handoffs.md reuse existing owner
|
||||
work: tenant agreement and client custody, KeyCape rollout, audit source
|
||||
onboarding, approval release, native lane activation and pinned combined
|
||||
runtime. Image/runtime preparation can proceed in parallel. The runner's
|
||||
project glas-local-proof must be reconciled with the owner route example's
|
||||
project glas-harness before the exact delivery binding is selected. No owner
|
||||
messages have been sent by this coordination work yet. T02 remains wait.
|
||||
|
|
|
|||
60
workplans/GLAS-WP-0015-production-dependency-coordination.md
Normal file
60
workplans/GLAS-WP-0015-production-dependency-coordination.md
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
---
|
||||
id: GLAS-WP-0015
|
||||
type: workplan
|
||||
title: "Drive owner returns for the first production Glas profile"
|
||||
domain: infotech
|
||||
repo: glas-harness
|
||||
status: active
|
||||
owner: codex
|
||||
topic_slug: production-dependency-coordination
|
||||
created: "2026-09-06"
|
||||
updated: "2026-09-06"
|
||||
---
|
||||
|
||||
# Production dependency coordination
|
||||
|
||||
GLAS-WP-0012 remains the real-profile acceptance workplan. This plan owns only
|
||||
concrete handoffs and receipt tracking from Glas; it does not duplicate owner
|
||||
implementation tasks or authorize credential access. User requested driving
|
||||
the dependencies from this repo after the policy-service production rollout.
|
||||
|
||||
## Prepare exact owner requests
|
||||
|
||||
```task
|
||||
id: GLAS-WP-0015-T01
|
||||
status: done
|
||||
priority: high
|
||||
```
|
||||
|
||||
Reviewed KEY-WP-0013, its existing provisioning packet, AUDIT-WP-0009-T09,
|
||||
APPROVAL-WP-0002, FLEX-WP-0021, SECRETS-WP-0009 and SAND-WP-0015. Prepared
|
||||
seven concrete requests in docs/production-dependency-handoffs.md. Includes
|
||||
live PDP coordinates, custody paths, tenant mismatch, audit startup critical
|
||||
path, independent image/runtime preparation, and proof project binding mismatch.
|
||||
|
||||
## Deliver and track owner handoffs
|
||||
|
||||
```task
|
||||
id: GLAS-WP-0015-T02
|
||||
status: wait
|
||||
priority: high
|
||||
```
|
||||
|
||||
Requests are prepared but not sent. Obtain explicit authorization to send
|
||||
State Hub coordination messages, then send deduplicated threaded handoffs to
|
||||
named owners and record actual receipt ids. Never mark delivery from file
|
||||
creation alone. A sent message is not accepted work or implementation evidence.
|
||||
|
||||
## Review owner returns against the acceptance gates
|
||||
|
||||
```task
|
||||
id: GLAS-WP-0015-T03
|
||||
status: wait
|
||||
priority: high
|
||||
```
|
||||
|
||||
Track tenant agreement, client custody/identity, audit onboarding, approval
|
||||
release, native activation and runtime binding against the linked owner tasks.
|
||||
Check revisions and positive/negative evidence; feed verified returns into
|
||||
GLAS-WP-0012-T02. Keep unfulfilled owner work live, and do not close this plan
|
||||
while actionable requests lack an owning record or acknowledged disposition.
|
||||
Loading…
Add table
Add a link
Reference in a new issue