feat: Add k8s_endpoint_public_access variable for private EKS

[pvenigal]

Summary

Plumbs endpoint_public_access on the upstream EKS module as a configurable variable so a deployment can opt into a fully private EKS API server. Today the value is hardcoded to true, meaning every dedicated-cloud and SaaS cluster has a publicly resolvable API endpoint (typically firewalled to a small CIDR allowlist).

Motivation: an upcoming THR (Texas Health Resources) dedicated-cloud deployment requires no public EKS endpoint at all. Without this change, that requirement can't be met without an out-of-band module fork.

Changes

• modules/eks/main.tf — endpoint_public_access reads from var.k8s_endpoint_public_access; endpoint_public_access_cidrs is conditionally null when public access is off (avoids phantom-diff UpdateClusterConfig calls in some hashicorp/aws provider versions when a non-null cidr list is paired with a disabled public endpoint).
• modules/eks/variables.tf — declares the new k8s_endpoint_public_access (bool, default true). Also adds default = [] to the existing k8s_public_access_cidrs so private-only deployments don't have to pass a meaningless allowlist value; description clarifies that the list is ignored when the public endpoint is disabled.
• variables.tf (top-level wrapper) — mirrors both variable changes so deployments calling the wrapper module can set them.
• main.tf (top-level wrapper) — threads k8s_endpoint_public_access through to the EKS submodule call. Linter realigned adjacent argument names; no semantic change there.

Backwards compatibility

Every existing deployment (evri, nocd2, disney, astrazeneca, pure, mede, shutterstock, saas/production, saas/production-dr, saas/staging) passes k8s_public_access_cidrs explicitly and does not reference the new variable. They get default true for the new bool, which preserves today's behavior exactly. The rendered terraform plan for any of them is byte-identical to pre-change. The default = [] on k8s_public_access_cidrs is a strict relaxation of a previously-required variable — every previously-valid input is still valid.

Operational note for the first private-EKS user

The terraform-aws-datafold module itself does not require EKS API connectivity during apply (no kubernetes or helm providers, no kubectl provisioners — only AWS APIs), so the initial infra/ apply can flip k8s_endpoint_public_access = false from day one without a chicken-and-egg problem.

However, downstream consumers (Datafold operator install, ArgoCD bootstrap, kubectl ops) do need EKS API connectivity. The expected bring-up for a private-only customer is:

1. Apply infra/ with k8s_endpoint_public_access = false and deploy_private_access = true — creates cluster + producer-side NLB + VPC endpoint service, publishes service name to SSM.
2. Apply the consumer-side dc_<customer>.tf in the networking backbone — reads SSM, creates the interface endpoint in the backbone VPC.
3. Engineers on Client VPN (already peered to backbone) can now reach the EKS API via PrivateLink; do the operator install from there.

The deploy_private_access + backbone consumer endpoint + VPN-to-PrivateLink path exists in code but has not carried customer EKS traffic in production. First customer should budget integration time for that.

Validation

• terraform fmt -check -recursive — clean
• terraform init -backend=false && terraform validate at module root — passes (only pre-existing warnings in external lambda_datadog module)
• terraform validate against an existing deployment (evri) using local-path module override — passes; confirms the module's external contract is unchanged for callers that don't set the new variable

Test plan

• CI passes (terraform fmt / validate)
• Reviewer confirms no behavior change for existing deployments by inspecting the conditional + default logic
• Once merged + released, THR deployment in cloud-infra pins the new module version and sets k8s_endpoint_public_access = false

[devops-datafold]

This PR is included in version 1.15.0 🎉