Use this lane when you need the production-style EKS baseline that keeps OpenBao as the public TLS endpoint.
This cloud baseline is the current hardened EKS reference shape validated by the project. It keeps the unseal root in AWS KMS, keeps the public hostname on a dedicated passthrough Gateway, and lets OpenBao manage ACME issuance directly while backup Jobs write to S3 through a separate identity.
This lane proves
- a Hardened-profile cluster can bootstrap on EKS with KMS auto-unseal and signed helper images
- OpenBao-managed ACME can issue and serve the public certificate while the Gateway remains pure passthrough
- JWT bootstrap, admin JWT login, and S3 backups all work under the same hardened cloud posture
- the dedicated public edge can stay separate from the terminating admin edge used for the rest of the platform
Cloud reference architecture. This is the production-style Amazon EKS baseline validated by the project.
Decision matrix
Lane summary
| Surface | Choice | Why it matters |
|---|---|---|
| Profile | spec.profile: Hardened | The lane proves the production-style posture rather than the relaxed bring-up defaults used in the development baseline. |
| Seal path | AWS KMS via workload identity | The main workload uses a cloud-native unseal path instead of static or external secret material. |
| TLS model | spec.tls.mode: ACME | OpenBao remains the TLS endpoint and owns the public certificate lifecycle directly. |
| Edge model | Dedicated public Gateway API passthrough | The hardened hostname stays isolated from the shared terminating admin edge and preserves tls-alpn-01 behavior. |
| Backup path | S3 with a separate backup identity | The lane proves that backup execution remains separate from KMS unseal and public-edge concerns. |
Diagram
Validated lane topology
The hardened hostname lives on its own passthrough edge, OpenBao handles ACME itself, and the cluster still keeps backup and unseal identity surfaces separate.
Why this lane exists
Reference table
Key design choices
| Choice | What it protects | Why it stays in the lane |
|---|---|---|
| Dedicated passthrough Gateway | The public OpenBao hostname keeps end-to-end TLS ownership inside OpenBao. | The hardened hostname should not inherit the operational compromises of a shared terminating admin edge. |
| OpenBao-managed ACME | Certificate issuance stays part of the OpenBao control surface. | The lane is meant to prove the operator plus OpenBao certificate path, not an external certificate controller. |
| Shared ACME cache | Multi-replica certificate state remains consistent across Pods. | The lane is not valid for HA ACME without an RWX-capable cache path. |
| Separate admin edge | Public ACME reachability does not force the rest of the platform onto the same public exposure contract. | The hardened lane needs this separation to stay operationally realistic. |
Stay on the validated path
- keep the hardened hostname publicly reachable on port
443for ACME validation - keep the public OpenBao hostname on a dedicated passthrough Gateway instead of the shared terminating edge
- keep the ACME shared cache on RWX-capable storage for multi-replica safety
- keep signed helper images and hardened verification enabled
- keep backup and unseal IAM roles separate so the security model you validated is the one you actually operate
The hardened EKS lane covered bootstrap, KMS auto-unseal, OpenBao-managed public ACME certificate issuance, Gateway passthrough, JWT bootstrap, human admin JWT login, and successful S3 backups.
This is not the right lane if you need a source-restricted public hostname, externally managed TLS, or a terminating Gateway in front of OpenBao. Those choices are different contracts, not small tweaks to this one.
Use the lane
You are reading docs for version 0.1.0. Use the version menu to switch to next or another archived release.
Was this page helpful?
Use Needs work to open a structured GitHub issue for this page. The Yes button only acknowledges the signal locally.