Ephemeral Castle Vault Runtime Architecture

The LushyCorp Vault runtime on Hetzner is a standalone secret-management track.

Unseal Strategy

TazLab uses a 2-of-3 Shamir threshold:

  • TazPod: Holds the full set of 3 recovery shares.
  • Hetzner Host: Holds exactly 2 shares for automated local unseal.
  • Restoration: Managed by the Classification and Restore logic.

Connectivity

Access is strictly restricted to the Tailscale Mesh. The historical runtime published the Vault API with the custom service identity https://lushycorp-api.ts.tazlab.net:8200, while the Tailscale-owned host identity in code was lushycorp-vm.ts.tazlab.net. During 09-vault-k8s-integration-prep Phase 1 validation on 2026-04-28, the runtime branch was converged toward the Tailscale-owned MagicDNS FQDN https://lushycorp-vault.magellanic-gondola.ts.net:8200, while the host still registered on the tailnet as lushycorp-vault.

The transport path was resolved on 2026-04-30 (TD-024, Closed). The TazPod runtime now defaults to hostnet+TUN mode (host network, /dev/net/tun, NET_ADMIN), with a helper tazpod-tailscale-up that starts Tailscale in kernel/TUN mode inside the container. The create.sh playbooks were split from one monolithic playbook into install/converge/post for clear per-stage timing, and render-tailscale-inventory.sh auto-detects TUN mode to generate direct-tailnet SSH inventory (no ProxyCommand).

Two access paths currently matter:

  • operator-side: TazPod containers use hostnet+TUN, running Tailscale in kernel mode. Transport is direct tailnet SSH — no tailscale nc shim. Full cycle validated at ~344s with zero transport timeouts.
  • cluster workloads: Talos nodes can egress to the Vault tailnet IP through the node OS bridge, but the .ts.tazlab.net name path is not yet automatically wired into workload DNS (Phase 2 of 09-vault-k8s-integration-prep)

Verified on 2026-04-27:

  • tailscale ping 100.67.102.77 from the dedicated Tailscale tool session succeeded for the Vault VM
  • a pod in external-secrets could open TCP to 100.67.102.77:8200
  • HTTPS from a pod succeeded when using explicit SNI/host mapping to the tailnet IP
  • plain pod DNS resolution of lushycorp-api.ts.tazlab.net did not yet point to the tailnet target

This verification also clarified that lushycorp-api.ts.tazlab.net is runtime-defined TLS/application glue, not a Tailscale-published MagicDNS name. The preferred future direction is therefore to converge the Vault API contract onto a Tailscale-owned hostname instead of preserving the custom alias as long-term doctrine; the accepted 09 branch now uses lushycorp-vault.magellanic-gondola.ts.net as that target contract.

The current canonical operator token for Vault API work is expected at ~/secrets/lushycorp-vault/admin-token.txt, but 2026-04-28 destroy/create validation also proved that the runtime does not classify TazPod state from /workspace/.tazpod/vault/vault.tar.aes directly. The classification depends on the decrypted canonical files materialized in ~/secrets/lushycorp-vault/. The follow-up remediation also re-established a healthy encrypted operator archive containing that canonical set and repopulated the S3 snapshot lineage under 61e17cbf-f522-4825-9bfe-444373173650.

See Also