railiance-platform/docs/credential-lane-designs/flex-auth-envelope-signing-native-adapter.md

Attended native signer custody adapter source

RPF-WP-0035-T12 / CUST-WP-0080. This source implements the protected native adapter described by the separate frozen native-preparation R1. It does not admit an execution. Its CLI is silent and intended only as the exact reviewed child of warden access openbao-platform-admin-login --exec in the founder's attended OIDC envelope. The existing Warden owner contains the token helper, checks child output and revokes/removes the session on exit. No new service, credential broker, standing grant, API or key-returning interface is created.

Current routing blocker

During preparation the required warden plan query for attended OpenBao platform administration of signer CAS0/metadata selected openbao-structure-survey with an approve ceremony, rather than openbao-platform-admin-login with oidc_login. The installed CLI reports wheel-bundled catalog0.1.2 fallback. This is preserved as a live refusal, not routed around. Exact route show names the existing active attended login, but that pointer does not cure dispatch. The adapter requires an independently retained routing receipt selecting the correct lane/verdict/identity act. No founder execution step is ready until the routing defect and all other native approvals are resolved by their owners.

Independent input and authority boundary

The CLI requires an absolute owner-private admission file, its independently approved exact SHA256, the exact private receipt directory selected in the reviewed native proposal, and an original receipt only for recovery. No default image/package/caller trust, founder identity, approval, route or source pin is usable. The admission schema is closed in validate_admission; it includes the immutable published producer image, retained caller, deployment projection, selected consumer trust baseline, exact native plan/CCR/source bundle, fresh UTC authority expiry (5..120seconds), founder entity and five distinct externally reviewed owner dispositions. Each disposition binds the same approval-free scope digest. An admission shape, local digest or review string never approves itself: the founder and owners must independently review the exact supplied command/file hash through existing governance before attended invocation.

The trust hash selects the independently reviewed consumer verifier/policy/trust baseline for this custody action. It is not a claim that the newly generated public key is already online: generation happens later, and independent delivery and successor trust installation are required after the public receipt. The writer never reads consumer private credentials or discovers trust from KV. All successful custody states remain pending independent public admission.

checked_sources verifies the actual selected native action plan, exact proposed kid, read CCR hash/status/binding, generated policy source, and source bundle. The read CCR must independently be approved/binding-confirmed; the canonical proposed CCR remains unapproved, so ordinary source checkout refuses. Source bundle pins execution modules, not arbitrary request-selected code. The native image/caller/seed projection is compared to the actual stopped Deployment. The lifecycle policy digest/version stays unchanged; execute-ccr probes must prove no ALLOW/effect. Current generic runtime guard can return HTTP503 before the lifecycle evaluator, so signed unknown_action is not promised.

Actual checks and effects

Before private work, the child checks OpenBao cluster ID, unsealed state, exact non-root platform-admin OIDC entity, enabled audit, actual exact read-policy HCL and role bindings/15m limits. The selected fixed loopback transport is the existing owner-admin bridge; Kubernetes reads use fixed strict-host SSH to railiance01. The OpenBao token lookup-self identifier stays only in the contained custody process to authenticate fixed HTTP calls; it never reaches the agent, a receipt, argv or another token file. This is a native protected-process implementation, not evidence that agent runtime isolation has been promoted or granted.

The fence checks the pinned kube-system UID, stopped Deployment generation and replica status, exact immutable image/caller/seed mount/kid projection, zero owned ReplicaSet replicas, no live or terminating signer-SA/owned/seed-mount pods, and no targeting HPA. It rechecks before metadata setup and immediately before CAS. A private filesystem lock excludes a second local custody window. The lock and observations do not provide atomic Kubernetes fencing: the independently reviewed exclusive window must keep GitOps/Helm/other creators stopped. No rollout or cluster mutation is performed by this adapter, and no concurrency guarantee is inferred from source alone. Access/cluster owners retain that admission.

Bootstrap requires the exact OpenBao empty-errors HTTP404 metadata absence. A durable private intent precedes exact CAS-required/max_versions2/no-auto-delete metadata setup, followed by exact native readback. Only then does the shared Ed25519 primitive generate one in-memory seed and CAS0 the fixed three-field KV document. Independent version1 private readback and final metadata verification precede the durable success receipt. The seed is never put in argv/env/local files or output. The receipt carries public key, ASCII-base64url fingerprint, version, bindings and closed phases only. The old fixture's live-dev-process gate is preserved; its shared receipt initialization was extracted without weakening that gate. Python cannot promise seed zeroization.

Every backend/body/close and tool call has a two-second absolute budget and 1MiB combined output bound. The complete operation is bounded by the supplied fresh expiry. CLI validation and runtime failures remain silent. Existing0600/ 0700 no-follow/ownership checks, exclusive creation, fsync/atomic replacement and directory fsync retain evidence. Same-UID hostile code is not isolated by modes; Warden's contained home, trusted runtime and independently reviewed custody location are required, not inferred from approval frequency or shell prefixes.

Process loss and independent read-only recovery

Any failed/ambiguous metadata/write/readback/final receipt outcome remains unconfirmed. A success receipt is withheld until final metadata verification. A child death immediately after the real native CAS leaves the earlier public intent with its derived public key and no private value. A fresh recover admission must bind that exact original receipt SHA and the same immutable scope. It reserves a new durable recovery intent before private reads, verifies current version1 metadata and exact private seed/public/kid correspondence, and records separate public reconciliation. It never creates a writer, generates a seed, POSTs metadata/data, restores a seed, consumes approval or dispatches business operations. Original unknown evidence is never rewritten. Changed versions, damaged/typed-invalid receipts, missing fresh reviews and denied reads refuse; replaying a recovery ID cannot repeat even the private backend read.

This source implements bootstrap and read-only version1 reconciliation only. Rotation needs a separately reviewed exact-version native action; the disposable primitive's CAS1 test is not a native rotation grant. No automatic retry, remint, rollback or general recovery API exists. Metadata-only setup uncertainty without a public seed intent requires separate attended reconciliation, not this path.

Access observed zero PVCs in flex-auth. Its proposed new1Gi/local-path outbox, PV Retain/reclaim disposition and runtime process-lock/capacity/startup bounds remain separate reviews. This writer grants no PVC, audit egress, policy role, SecretStore/Secret or producer/consumer deployment admission.

R2 phase-aware recovery and source lineage

Frozen R1's metadata-only crash counterexample remains valid historical evidence. R2 accepts a strict original metadata-setup receipt with no public key, or a seed-cas receipt with a canonical derived public key. Fresh recovery reserves durable evidence before target reads. Exact current metadata absence AND exact version1 data absence yields current-custody-absent. Exact configured metadata with current_version0 AND exact version1 data absence yields metadata-only-confirmed. Both results have no public key/fingerprint/KV version, key_custody_verified=false, historical_effect=unresolved, original_unknown_preserved, and an explicit fresh independently reviewed action requirement. A locally generated but unstored seed's public key is not promoted into public admission. Neither observation means the original attempt historically made no effects.

Denied/malformed/misleading404 metadata or data, timeout, changed configuration, unexpected versions, or version1 after a metadata-only/no-public phase keep the new recovery attempt unconfirmed. They never grant generation, write, retry, remint, consume or business authority. A subsequent metadata-only bootstrap is not silently enabled: existing metadata still refuses CAS0 bootstrap admission. A distinct exact reviewed action/source revision must choose any cleanup/reuse or generation step. The original receipt remains byte-for-byte unchanged.

Native plan bootstrap.source_primitive_sha256 now equals the actual shared primitive in the admitted source bundle and writer receipt; checked_sources enforces the join. The prior8ed pin is explicitly historical. The plan pins the shared primitive, not itself or the complete native executor, so no self-hash cycle exists. The exact native executor is independently pinned by source_bundle and its digest in bindings. A recover admission must additionally supply original_execution (original receipt bindings, writer SHA and CCR SHA). Fresh owner reviews bind both original and current lineages. This can describe an older executed source/proposal without labeling it current. Image/deployment/policy/ consumer trust bindings must still match; recovery cannot change that authority.

Exact120-second expiry and attended scheduling assessment

The unchanged validate_admission rule requires an absolute UTC expires_at with 5 < expires_at-now <=120seconds, and the entire child runs beneath that fixed remaining absolute/monotonic budget. The five external reviews cover the scope digest including expires_at. No deadline is generated, refreshed or widened by the child; rechecking cannot extend it.

Existing ops-warden proxy.proxy_attended_login_exec runs the OIDC client before the child. Its _contained_run captures output through subprocess.run without a timeout. Therefore neither OIDC/MFA nor five external reviews have a demonstrated bound that fits120seconds from preparing an admission. Creating a now+120seconds admission before unbounded review/login is not a reliable operational ceremony. Source success tests start from synthetic ready identities; they prove no human OIDC/review timing SLO.

A coherent ceremony under the current rule is to pre-review one exact future absolute expiry/window, including all artifact/source/image/trust/identity and review references, then arrange attended login so the child starts within its implicit [expires_at-120seconds, expires_at-5seconds) interval. Review may occur before that interval; it does not change runtime authority. The founder must aim for the beginning of the interval, not its last five seconds. The fixed path has 26 bounded native/tool requests before success (52seconds at their2second caps), plus key/source/receipt work. Its expiry still wins if those operations cannot finish; no completion or filesystem timing guarantee is inferred.

If login completes too early/late, a review changes any bytes, or adequate time remains uncertain, refuse this revision. A new expires_at changes the approved scope digest and needs explicit dispositions for the new revision; existing source-only reviews cannot be copied into native approval. Do not silently refresh after OIDC, reinterpret expiry as start-only, widen120seconds, skip reviews or start a general window-grant service. An alternative authority/window contract would itself require separate owner/founder design and is not supplied by R2. Current native admission remains unapproved.

R3 precise owner review boundary

The native review slot is now cluster-runtime-storage-owner, held by railiance-cluster for runtime/storage/headroom only. The previous cluster-gitops-owner slot conflated separate authorities and is rejected; no historic review is reinterpreted as a combined assent. Platform's existing review covers its custody/read lane and existing GitOps Applications/freeze integration. Access retains workload/release/Helm-values and signer/outbox ownership. Enablement review is needed only when the action actually changes ArgoCD installation/controller configuration; this action does not authorize that. Changed scope requires a separate exact revision and any affected owner.

This is a source-schema correction, not a new approval. Existing R1/R2 source reviews and P1/P2 packets remain frozen. A successor packet must pin the new executor/source-bundle/plan/CCR hashes and collect five exact fresh dispositions under the corrected role set. Admission-file digest approval and CCR approved/binding-confirmed status/native checks remain unchanged.