Local hardened lane with external TLS

This validated local baseline covers a hardened deployment with external TLS, an external seal dependency, and user-managed TCP passthrough.

Validated coverage

• 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

Baseline scope

This local reference architecture uses k3d to rehearse a hardened deployment with an external seal provider and externally managed certificates. It is a local validation lane rather than a production target.

Decision matrix

Baseline summary

Baseline 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 baseline exercises a real external dependency rather than 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 baseline covers bootstrap, unseal, admin JWT login, and passthrough access in a repeatable local rehearsal path.

Diagram

Baseline 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.

Baseline requirements

• 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

Validated coverage

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.

Out of scope

This lane does not define a cloud reference or a GitOps reference. It is a local rehearsal environment for hardened bootstrap, external TLS, and passthrough access with explicit external dependencies.

Next steps

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.