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.

Classification

Cloud reference architecture. This is the production-style Amazon EKS baseline validated by the project.

Decision matrix

Lane summary

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

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 443 for 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

What this lane validated

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.

What this lane is not

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

Deployment recipeApply the exact EKS hardened lane with KMS, public ACME, dedicated passthrough, and S3 backup wiring.TLS and workload identityReview the generic TLS ownership and workload-identity model behind the lane.Platform controlsCross-check the hardened cloud lane against the admission, RBAC, and network controls the rest of the docs recommend.