net-kingdom/sso-mfa/k8s/keycape/registration-adapter.md

Attended registration adapter candidate

Exercise status: unexercised

This is a source-only, injection-only adapter for the existing Warden closed kernel. It installs no command, runtime dispatcher, credential provider, evidence trust root or new service. NetKingdom type/case status and bytes remain unchanged. The generated descriptor is a proposal; it is not owner acknowledgment.

keycape-registration-adapter.py wraps maintained keycape-client.run in apply mode. A fixed invocation binds principal, human actor, lane, case/type/descriptor/ catalog/acceptance/run-sheet digests and target. The descriptor pins this adapter and its complete local helper import closure together with the exact reviewed check-config executable digest. Changing that digest changes the descriptor source pin and descriptor bytes, requiring independently reviewed admission. The selected artifact path is rehashed before each attempt. Before helper access, the adapter also reads that regular file with final-component symlinks refused, checks the descriptor's exact digest, and copies at most 64 MiB into a Linux memfd sealed against write, shrink, growth and seal removal. Both live and proposed checks execute this same snapshot through /proc/self/fd, inherited only by the checker subprocess with an empty environment. The descriptor still binds the original artifact digest and adapter/helper composition, never an ephemeral fd pathname. Changing the selected file after snapshot creation cannot change executed bytes. Snapshot/seal/exec failures close the fd, revoke the parent session through the existing boundary and cannot create a success receipt. Linux memfd seals, executable memfds and accessible procfs are required; unsupported runtime policy fails closed. This does not prove trusted native storage, protect against a compromised interpreter/kernel or supply process isolation. The helper resolves the selected file to an absolute executable path and supplies an empty checker environment, so ambient PATH and KeyCape URL overrides cannot select another executable or alter validation of supplied bytes. Standalone helper path selection still does not establish immutable storage. Native executable custody and runtime admission remain separate requirements. The caller constructs the proposed invocation from exact source inputs, installs the fixed adapter once, and calls normal Executor.admit; independently derived admission must match. No callable replacement after admission is required or supported by this recipe.

The operation uses existing cluster/issuer checks, byte-preserving merge, Deployment secret-env prerequisite, config validation, UID/resourceVersion CAS and whole-data readback. Only closed metadata is passed to the injected durable owner publisher. The owner authenticator must independently authenticate those exact bytes. The session-revocation capability must end the same attempt's parent session; Warden separately verifies its exact revocation evidence. These capabilities are owner-selected callables, never case-supplied commands. No implementation of these native capabilities is supplied or implied here.

An identical existing client returns no change and creates no rollback authority. Removal requires this process's independently authenticated successful creation receipt, exact created-object label, unchanged postcreation UID/resourceVersion, and the original exact client record. External drift, a lost readback, receipt publication/revocation failure or process loss requires owner reconciliation. No uncertainty is labeled retry-safe. No automatic reconciliation is installed. Rollback after restart intentionally remains unavailable until an owner supplies independently authenticated durable creation provenance and reviews recovery.

The source tests execute actual maintained helper CAS/readback against synthetic Kubernetes objects. Three checks exercise actual Warden admission/run/rollback and uncertainty transitions with synthetic owner trust. Warden d97652a's exact published producer source pins apply unchanged through actual BrowserInputs. This is a source compatibility fixture, not acknowledgment, owner provenance, normal native admission or deployment acceptance.

Original-intent reconciliation (NK-WP-0048-T15 source)

build(..., holder=, observe=) takes two optional read-only capabilities, injected together or not at all. With them the Adapter installs reconcile_original for Warden's ReconcileContext (ops-warden a45cf47): the original run intent must be separate from the reconcile attempt and both must match the admitted case and reviewed source; holder(original_attempt_id) must return exactly one record that authenticate accepts, naming that invocation and source with a created-only success; and observe() must show the recorded post-creation uid/resourceVersion with the exact client entry. The parent session is revoked either way, and a netkingdom.keycape-registration.reconcile.v1 record is published; verify accepts that result like any other owner record. It never adds or removes: holder outage, missing/ambiguous/unauthenticated or foreign records, a no-change original, and changed revision or entry all raise, so Warden keeps the step uncertain. Rollback after restart stays refused, since a reconciled creation is not a creation this process verified, until an owner rollback contract exists. Which authenticated holder backs holder is an owner gate; the tests use an in-memory stand-in only.

Remaining work belongs in live work records before T12 closure:

• Warden owns global evidence admission and exact native evidence/session capabilities. Published d97652a refreshes BrowserInputs producer pins for NetKingdom 015694ee; that source assent does not attest this new adapter.
• NetKingdom owns separately reviewed descriptor/type pin selection, the env binding/config/restart steps, and group ensure/revoke provenance. Current group ensure does not report newly added memberships; current revoke can remove memberships that predate the case. Wrapping these as reversible creation would be unsound. Preserve them until a reviewed created-only contract exists.
• Platform owns structural/mint/broker and secret delivery evidence; Apps owns actual consumer login and group enforcement. No assent is supplied here.
• Attended use still requires existing owner authorization, current caller identity, native source/config/image pins, native receipts and cleanup proof.