Gardener apiServer: missing enforcement of private-only mode across clouds

Short answer

No. Gardener does not document a single boolean that guarantees identical private-only API server enforcement across AWS, GCP, and Azure. The Shoot spec exposes an API server privacy setting (commonly apiServer.privateEndpoint or a provider-equivalent field), but each cloud controller translates it differently, and older Gardener releases may not create internal load balancers at all.

Likely explanation versus confirmed facts

Likely explanation: When enabled, Gardener’s provider controller attempts to provision an internal endpoint: AWS sets the load balancer scheme to internal, GCP uses an internal load balancer or private service attachment, and Azure uses an internal load balancer with network security group rules. The seed cluster is expected to reach that endpoint through VPC peering, VPN, or Dedicated Interconnect.

Confirmed facts: Gardener shoot specs include API server network controls; cloud controllers implement provider-specific networking; the seed must have a network path to the shoot control plane IP. Behavior depends on Gardener release and provider API versions, so exact field names and fallback behavior are not uniform.

Uncertainty: Whether Gardener falls back to a public load balancer when an internal load balancer cannot be created, and whether network policies alone can reliably block public traffic in that fallback, requires verification against your release notes.

Steps for this case

1. Check your Gardener version and the provider-specific release notes for apiServer.privateEndpoint support.
2. Set the private endpoint field to true in the Shoot manifest and apply it.
3. Confirm in the cloud console that the API server load balancer is internal-only (AWS scheme internal, GCP internal LB, Azure internal LB).
4. Add the seed cluster’s CIDR ranges to the security group, network security group, or firewall rule attached to that load balancer.
5. Verify connectivity from the seed to the shoot API server’s internal IP before restricting any further.

Missing diagnostic detail

Which Gardener version and cloud provider are you running? The answer changes whether privateEndpoint is supported and what happens if an internal load balancer cannot be provisioned.

Verification

kubectl get shoot <name> -o yaml | grep -A5 apiServer

Then inspect the provider console for the load balancer scheme and attached network rules. From a pod in the seed network, test curl -v https://<shoot-api-internal-ip>:6443 to confirm reachability.