Hardened EKS baseline with public ACME

This cloud baseline is the hardened EKS topology validated by the project. It uses AWS KMS for auto-unseal, a dedicated public passthrough Gateway, OpenBao-managed ACME, and S3 backups through a separate identity.

Validated coverage

• 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

Baseline scope

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

Decision matrix

Baseline summary

Baseline summary.

Surface	Choice	Why it matters
Profile	spec.profile: Hardened	The baseline uses the hardened production-style posture rather than the development baseline defaults.
Seal path	AWS KMS via workload identity	The main workload uses a cloud-native unseal path rather than 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	Backup execution remains separate from KMS unseal and public-edge concerns.

Diagram

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

Baseline requirements

• 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

Validated coverage

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.

Out of scope

This baseline does not cover source-restricted public hostnames, externally managed TLS, or a terminating Gateway in front of OpenBao. Those choices require a different topology.

Next steps

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.