Use this lane to rehearse a hardened deployment with external certificates and a separate unseal root.

This local baseline is the closest validated rehearsal path to a hardened deployment that keeps TLS outside the operator, keeps the seal dependency external, and exposes OpenBao through user-managed TCP passthrough instead of a shared terminating edge.

This lane proves

• a Hardened cluster can bootstrap locally without falling back to operator-managed TLS or static unseal
• Transit auto-unseal can stay outside the cluster while self-init and JWT bootstrap still succeed
• externally managed TLS Secrets and passthrough traffic can remain separate from the operator's edge integration model
• the local environment can rehearse a production-style trust split without pretending k3d itself is the production target

Classification

Local reference architecture. k3d is not the production target, but this lane is the closest validated local analogue to a hardened deployment with an external seal provider and externally managed certificates.

Decision matrix

Lane summary

Lane summary.

Surface	Choice	Why it matters
Profile	spec.profile: Hardened	The lane is valuable only if the operator enforces the production-style posture and rejects the relaxed development shortcuts.
Seal path	External Transit provider	The unseal root stays outside the cluster so the lane tests a real external dependency instead of collapsing back into static secrets.
TLS model	spec.tls.mode: External with externally provisioned Secrets	Certificate lifecycle stays separate from the operator, which is the point of the lane.
Edge model	User-managed Traefik TCP passthrough	The validated path keeps passthrough isolated from any shared terminating listener and treats edge routing as a deliberate external dependency.
Validation scope	Local validation environment plus hardened E2E lifecycle coverage	The lane proves bootstrap, unseal, admin JWT login, and passthrough access in a repeatable local rehearsal path.

Diagram

Validated lane topology

The lane keeps the unseal root external, keeps TLS external, and keeps the passthrough path user-managed. That separation is the reason this local baseline is useful.

Why this lane exists

Reference table

Key design choices

Key design choices.

Choice	What it protects	Why it stays in the lane
Transit stays external	The seal root is not stored or derived from the cluster itself.	A hardened rehearsal lane should prove the dependency on an external seal provider instead of hiding it.
TLS stays external	Certificate issuance and trust material do not collapse into operator-managed defaults.	This keeps the certificate contract aligned with the kind of deployment that already has an external PKI owner.
Passthrough is user-managed	The OpenBao server remains the TLS endpoint.	The lane intentionally avoids turning shared ingress behavior into part of the hardened contract.

Stay on the validated path

• keep spec.profile: Hardened
• keep the shared Transit provider reachable and trusted
• keep tls.mode: External and provide the expected CA and server Secrets
• keep the passthrough route managed outside spec.gateway
• disable AppArmor only when the local runtime requires it and treat that as a local-environment concession, not a preferred default

What this lane validated

The validated local lane exercised hardened bootstrap with self-init, Transit auto-unseal through a shared external OpenBao service, JWT login for a human admin ServiceAccount, and passthrough external access with externally managed TLS Secrets.

What this lane is not

This is not a cloud reference, not a GitOps reference, and not proof that spec.gateway itself is the right path for hardened passthrough. It is a local rehearsal lane with explicit external dependencies.

Use the lane

Deployment recipeFollow the exact steps that reproduce this validated lane in the local environment.External accessCompare the lane's user-managed passthrough choice with the generic service-boundary guidance in the main docs.TLS and identityReview the security model behind external certificates and server-side TLS ownership.