EKS development baseline with AWS integrations

This cloud baseline keeps the posture intentionally Development while validating the AWS integrations needed for cloud bring-up: KMS auto-unseal, workload identity, shared-edge exposure, JWT bootstrap, and snapshot upload to S3.

Validated coverage

• 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

Baseline scope

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

Baseline summary

Baseline 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 uses cloud auto-unseal through AWS KMS rather than local or static secret material.
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	Backup execution stays separate from the main KMS identity surface.
Validation scope	Manual EKS validation plus operator lifecycle behavior	The baseline covers the cloud integration path used in the validated EKS development environment.

Diagram

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

Baseline requirements

• 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

Validated coverage

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.

Out of scope

This baseline does not cover the hardened public-endpoint path, ACME passthrough, or a final production posture. It covers the AWS control-plane integrations used in the validated development environment.

Next steps

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.