GKE compute environments: connect via the DNS-based control-plane endpoint
Rob Syme
Problem:
Platform drives GKE clusters through the control plane's IP endpoint. Security-conscious customers increasingly run private-endpoint-only clusters (
enablePrivateEndpoint=true
, often with privateEndpointEnforcementEnabled=true
), where the control plane has no public IP and no authorized-networks entry can admit Seqera Cloud. For these customers, GKE compute environment creation fails at the reachability probe, and today their only supported choices give something up: Google Batch (no Kubernetes), a re-enabled restricted public endpoint (posture change), the generic Kubernetes CE over the DNS endpoint (no Fusion, no Data Explorer on work dirs), or Enterprise (deployment change).Proposal:
Every GKE cluster has a second control-plane endpoint: a DNS name (
controlPlaneEndpointsConfig.dnsEndpointConfig.endpoint
, GA 2024-11-11, always present) served through Google Front End and authenticated by IAM (container.clusters.connect
) instead of source IP. GKE compute environments should prefer it when enabled (allowExternalTraffic=true
), falling back to the IP endpoint otherwise. That makes private-endpoint-only clusters work from Seqera Cloud with no change to the cluster's network posture and the full GKE feature set intact - Fusion, Wave, Data Explorer, log retrieval.