Use this lane to validate the EKS bring-up path with real AWS integrations before you move to a hardened public endpoint.

This cloud baseline keeps the posture intentionally Development, but it proves the integrations that matter for cloud bring-up: KMS auto-unseal, workload identity, shared-edge exposure, JWT bootstrap, and snapshot upload to S3.

This lane proves

• a Development-profile cluster can bootstrap on EKS with AWS KMS auto-unseal and no static root-token workflow
• JWT bootstrap and human admin JWT access both work under the cloud control-plane conditions EKS introduces
• a shared terminating Gateway can expose the development cluster without requiring passthrough or public ACME
• backup Jobs can authenticate separately from the main workload and write snapshots to S3 successfully

Classification

Cloud reference architecture. This is a realistic EKS validation and bring-up topology, but it is intentionally a Development lane rather than a production target.

Decision matrix

Lane summary

Lane summary.

Surface	Choice	Why it matters
Profile	spec.profile: Development	The lane is meant for cloud bring-up, demos, and operational validation, not for a production-ready posture.
Seal path	AWS KMS via workload identity	The main workload proves real cloud auto-unseal behavior instead of a local or static secret fallback.
Edge model	Shared terminating Gateway API edge	The lane keeps public routing simple and avoids ACME passthrough complexity during bring-up.
Backup path	S3 with a separate backup identity	The lane proves that backup execution stays separate from the main KMS identity surface.
Validation scope	Manual EKS validation plus operator lifecycle behavior	The lane proves the cloud integration path you need before deciding whether to harden the endpoint.

Diagram

Validated lane topology

The main workload uses one cloud identity for KMS, backup Jobs use another for S3, and the public edge remains a shared terminating layer rather than a dedicated passthrough stack.

Why this lane exists

Reference table

Key design choices

Key design choices.

Choice	What it optimizes	Why it stays in the lane
Shared terminating edge	Simple cloud bring-up with a familiar ingress model.	The lane is for proving integrations quickly, not for rehearsing production passthrough behavior.
Separate KMS and backup identities	Unseal permissions and object-storage permissions stay decoupled.	This is the cloud-specific security boundary the lane needs to prove before a hardened rollout.
Development profile	Fast bring-up and low-friction validation on real infrastructure.	The lane should prove AWS integrations without also forcing the full public-ACME hardening path.

Stay on the validated path

• keep spec.profile: Development and treat the lane as bring-up coverage, not a production recommendation
• keep the shared terminating edge and do not switch the same lane to passthrough midstream
• keep separate IAM paths for KMS and S3 so backup behavior is actually validated
• keep JWT bootstrap enabled for both operator-owned auth and human admin access
• use a bucket, region, and Gateway path that are all reachable from the exact EKS environment you are validating

What this lane validated

The EKS development lane covered bootstrap, AWS KMS auto-unseal, JWT bootstrap on EKS, human admin JWT login, Gateway exposure through the shared edge, and successful S3 backups.

What this lane is not

This is not a hardened public-endpoint reference, not proof of ACME passthrough, and not a final production posture. It is the shortest cloud lane that still proves the important AWS control-plane integrations.

Use the lane

Deployment recipeApply the exact EKS development lane with KMS, shared-edge exposure, and S3 backup wiring.Backup operationsReview the generic backup model behind the lane's S3 configuration and retention behavior.EKS HardenedMove to the hardened cloud baseline when you need public ACME and a dedicated passthrough edge.