railiance-cluster/docs/keycape-tls-recovery-boundary.md
codex c562d7134c
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
CI Smoke / container-smoke (push) Successful in 2s
feat(recovery): prepare owner-bound offline TLS continuity preflight
Assistant: codex
Assistant-Model: gpt-6.1-sol
Assistant-Session: 01a1468b-63fa-7710-85dc-8f2e16b3ebfa
2026-10-17 02:12:35 +02:00

51 lines
3.1 KiB
Markdown

# Original KeyCape TLS recovery boundary
Source disposition, 2026-10-17, scoped to railiance-cluster INTENT: cluster runtime,
ingress/certificate plumbing and backup posture. This is source preparation only.
It is not native acceptance, an issuer/key custody assent, a reissue decision or
permission to mutate the cluster.
NetKingdom's ingress source names `kc.coulomb.social`, `sso/kc-tls`,
`ClusterIssuer/letsencrypt-prod` and Traefik termination before KeyCape8080.
NetKingdom owns that namespace intent; railiance-cluster owns cert-manager,
ingress controller and cluster backup posture. No inspected source establishes
who independently holds the original private TLS recovery material when the
ordinary issuer/cluster is unavailable. A missing exact routing-catalog entry
cannot prove absence of an owning subsystem.
The identity archive excludes `kc-tls`. Current S2 backup source encrypts SQLite
state, Helm values and kubeconfig to the same host's `/opt/backup/railiance/cluster`
and retains seven versions. No inspected source proves an actually fresh,
independent offsite object or original certificate/key/trust recovery. Archived
RAIL-BS-WP-0004 is historical local-backup delivery; backlog RCLUSTER-WP-0007-T05
is gated HA issuance/renewal; active RCLUSTER-WP-0017 is signer runtime/storage.
None is an existing live task for this original TLS recovery demand.
`railiance-backup-s2` also stages raw state/Helm output in named `/tmp` paths
without early hard-loss cleanup; `railiance-restore-s2` prints whole-state restore
instructions. Do not use either as an isolated TLS extraction path. RCLUSTER-WP-0018
tracks exact inventory, safe private staging/extraction preparation where required,
independent outage proof and future archive-boundary disposition. No original
ciphertext or historical outcome is rewritten by that work.
`tools/public-tls-metadata.py` is an offline public-only step. After the source
owner identifies independent original **public certificate/chain and trust files**:
```sh
python3 tools/public-tls-metadata.py --public-cert ORIGINAL_PUBLIC_CERT_CHAIN.pem --public-trust ORIGINAL_PUBLIC_TRUST.pem
```
It accepts no private-key argument, bounds regular-file reads, refuses symlinks and
non-certificate PEM material, and reports public hashes/SANs/validity/counts only.
The file names are owner-local placeholders, not a key request. Output establishes
public metadata, not originality, hostname/chain acceptance, reissue permission or
custody. Do not supply a Secret object or combined certificate/key PEM. Fail closed
when original source, trust or exact bindings are missing; no fresh self-signed
trust workaround is admitted.
For FUTURE NetKingdom archives, the source owners must explicitly disposition
original TLS coverage or a reviewed reissue contract: producer/custody owner,
private artifact boundary, offline recovery independence, original public hashes,
scoped capture/read permissions, retention and native verification. Merely adding
`kc-tls` to secret_refs would change capture/permission/custody scope and is not
authorized by this source review. It cannot repair the current archive retroactively.