Securing GKE Control Plane Access with DNS-Based Endpoints

We all love private Google Kubernetes Engine (GKE) clusters. Locking down your control plane so it isn't exposed to the public internet is Kubernetes Security 101. However, the moment you try to hook up your CI/CD pipeline, like GitHub Actions running on hosted runners, you hit a classic architectural brick wall.

GitHub's hosted runners use a massive, dynamically changing pool of public IP addresses. Traditionally, you had to choose between two painful options:

While proxy architectures work brilliantly for tools natively embedded in your Google Cloud environment, setting them up for external CI/CD platforms adds unnecessary operational overhead and maintenance debt.

Fortunately, in the modern day, there is a better and improved way! By leveraging GKE DNS-Based Endpoints alongside Workload Identity Federation (WIF), you can grant your external GitHub Actions workflows secure, direct access to your private cluster control plane without maintaining a single piece of proxy infrastructure.

Shifting from Network Security to IAM-Gated Security

GKE DNS-based endpoints fundamentally change how external traffic is handled by the GKE control plane. Instead of relying solely on network-level IP whitelisting via Master Authorized Networks, this feature introduces a DNS-only, IAM-gated endpoint (*.gke.goog).

When you allow external traffic through a DNS endpoint, the endpoint is technically resolvable over the internet, but network access alone gets you nowhere. Every single request hitting that endpoint must be explicitly authenticated and authorized via Google Cloud IAM.

This allows you to securely execute a "merge-before-apply" GitOps workflow directly from standard GitHub-hosted runners:

Strict Least Privilege: The runner only possesses short-lived tokens with tightly scoped IAM permissions to manage the cluster.

Architectural Blueprint

In a highly hardened enterprise landing zone, the DNS-based endpoint serves as the secure, clean management line connecting your external control planes to your private workloads.

Here is how it integrates into a comprehensive security architecture:

‌

Implementing DNS Endpoints with Terraform

Bringing this architecture to life is straightforward. To keep things focused, the production-ready snippet below showcases solely the configuration required to enable the DNS-based endpoint and application-layer secrets encryption.

We will leave out the rest of the standard GKE cluster and node pool boilerplate definitions for now.In your GKE Terraform module, you need to configure the control_plane_endpoints_config block inside the google_container_cluster resource, while keeping your cluster network-private.

resource "google_container_cluster" "primary" {
  # ... other configurations/settings ...

  # Isolate your node infrastructure strictly inside the private network
  private_cluster_config {
    enable_private_nodes    = true
    enable_private_endpoint = true
    
    # Use your own custom private /28 CIDR range here
    master_ipv4_cidr_block  = var.master_ipv4_cidr_block 
  }

  ### WHERE THE MAGIC HAPPENS ###
  
  # Leave out the network-level IP whitelisting entirely (MAN).
  # No more maintaining brittle, shifting lists of public CI/CD runner IPs.
  master_authorized_networks_config {}

  # Expose a public, cryptographically IAM-gated DNS endpoint.
  # This allows authenticated external platforms (like GitHub Actions) to safely reach the cluster API using identity verification instead of an IP address.
  control_plane_endpoints_config {
    dns_endpoint_config {
      allow_external_traffic = true
    }
  }

  # ... other configurations/settings ...
}

Important Security Note

DNS-based endpoints remove the need for bastion hosts and large IP allowlists, but they also shift your security boundary from the network layer to the identity layer.

With Master Authorized Networks (MAN), only trusted IPs could reach the control plane. With DNS-based endpoints, access is protected through IAM and Workload Identity Federation (WIF) instead.

That means your WIF configuration becomes critical. A misconfigured WIF binding or overly broad IAM permissions could unintentionally expose cluster access.

To keep this setup secure:

When properly configured, this provides a strong zero-trust model without the operational overhead of proxy infrastructure.

Summary of Benefits

By modernizing your private GKE access strategy with DNS-based endpoints, additional hardening, you achieve a zero-trust architecture without operational headaches:

True Zero-Trust Security: Perimeter security is fragile. Shifting your security posture to cryptographically validated identities (OIDC + IAM) guarantees that even if an attacker discovers your cluster's DNS name, they cannot access it without valid cloud credentials.

Useful Links

Interested in setting up Workload Identity Federation (WIF) with GitHub Actions?

Interested in another secure approach using an IAP Proxy?