Local hardened lane with private ACME
This validated local baseline keeps the hardened posture, keeps the unseal root external, and keeps OpenBao as the TLS endpoint while an internal ACME CA validates certificate issuance through a user-managed passthrough edge.
Validated coverage
- a Hardened cluster can bootstrap locally while keeping the seal dependency outside the tenant namespace
- OpenBao-managed ACME issuance works when the validator reaches the passthrough edge with the expected hostname
- Transit auto-unseal and ACME trust material can coexist in one shared trust-services dependency
- local rehearsal covers ACME readiness and probe behavior before a public-cloud baseline
This local reference architecture uses k3d to rehearse hardened deployments that keep TLS passthrough in OpenBao and use a private ACME trust chain. It is a local validation lane rather than a production target.
Decision matrix
Baseline summary
| Surface | Choice | Why it matters |
|---|---|---|
| Profile | spec.profile: Hardened | The lane only matters if the operator enforces the hardened policy surface while ACME and Transit are both active. |
| Seal path | Shared external OpenBao Transit provider | The seal root stays outside the cluster, which keeps the lane aligned with a real external dependency model. |
| TLS model | spec.tls.mode: ACME with an internal ACME CA | OpenBao remains the TLS endpoint while the lane avoids dependence on public ACME during local validation. |
| Edge model | User-managed Traefik TCP passthrough | TLS must reach OpenBao untouched for ACME, so the edge must pass traffic through instead of terminating it. |
| Validation scope | Local ACME lifecycle coverage plus hardened bootstrap | The baseline covers ACME readiness, trust material, and bootstrap behavior together. |
Diagram
Baseline topology
The same external trust-services dependency supplies both Transit auto-unseal and the private ACME directory, while the ingress layer remains pure passthrough.
Why this lane exists
Reference table
Key design choices
| Choice | What it protects | Why it stays in the lane |
|---|---|---|
| Private ACME issuer | The lane can prove ACME behavior without assuming public DNS and internet reachability. | Local hardened rehearsal should prove OpenBao-managed issuance, not public CA operations. |
| Hostname resolves back to the passthrough edge | The validator actually reaches the endpoint OpenBao serves for tls-alpn-01. | Successful name resolution is the invariant; the local CoreDNS rewrite is only one implementation of it. |
| Shared trust-services dependency | Transit and ACME both depend on the same external trust boundary. | This keeps the local lane close to the production-style trust split without requiring cloud services. |
| Passthrough stays user-managed | OpenBao remains the TLS endpoint. | The lane intentionally avoids making shared terminating ingress behavior part of the hardened ACME contract. |
Baseline requirements
- keep
spec.profile: Hardenedand keep the trust-services endpoint reachable for both Transit and ACME - keep the ACME hostname resolving back to the passthrough edge from the validating environment
- keep the passthrough route targeting the dedicated
-acmeService on port443 - mount both the Transit CA bundle and the ACME issuer CA bundle in the Secret expected by the lane
- disable AppArmor only when the local runtime forces it and treat that as a local node concession
The validated local lane exercised hardened bootstrap with self-init, Transit auto-unseal through shared trust services, OpenBao-managed ACME issuance from a private CA, human admin JWT login, and external access over user-managed passthrough.
This lane does not prove public ACME behavior or replace a cloud ingress baseline. It is a local rehearsal environment for the hardened ACME control path.
Next steps
You are reading the unreleased main docs. Use the version menu for the newest published release, or check the release notes for what is already out.
Was this page helpful?
Use Needs work to open a structured GitHub issue for this page. The Yes button only acknowledges the signal locally.