Professional Cloud Network Engineer

Configure Private Cluster Access using DNS Endpoints

DNS-Based Endpoint Benefits and Configuration

A DNS-based endpoint for a Google Kubernetes Engine (GKE) cluster's control plane uses DNS resolution of the source traffic rather than static IP addresses to decide whether access is allowed. When you enable this endpoint by passing the --enable-dns-access flag during cluster creation, the control plane becomes accessible from any network that can reach Google Cloud APIs, including on-premises data centers and other cloud provider networks. The access policy is based on Identity and Access Management (IAM) permissions, so you no longer need to maintain static IP allow-lists (authorized networks) for every possible source network. This flexibility makes the DNS-based endpoint especially useful for organizations with dynamic or distributed infrastructure.

Relationship to Private Google Access and Network Architecture

The DNS-based endpoint works together with Private Google Access to keep control plane traffic entirely within Google's network. When a client resolves the cluster's endpoint DNS name, the connection reaches Google's frontend infrastructure, which routes the request internally to the cluster's private control plane. This flow is essential for private clusters, where the control plane has a private IP address. The architecture depends on the client's ability to resolve and reach Google's API endpoints, which Private Google Access provides for resources that lack external IP addresses.

Implications for Hybrid and Multi-Cloud Access

The DNS-based endpoint is valuable for hybrid and multi-cloud architectures because it overcomes the non-transitive nature of VPC Network Peering. In a hub-and-spoke topology where the GKE cluster resides in a spoke VPC, direct access to the control plane from another spoke or on-premises network is not possible through peering alone. The DNS endpoint, accessible via Google's APIs, provides a path for this access without requiring a network proxy or agent in the cluster's VPC, simplifying the network design for decentralized clusters.

Security Integration with VPC Service Controls

For environments that need stringent data security, the DNS-based endpoint can be protected inside a VPC Service Controls perimeter. This configuration ensures that requests to the control plane are evaluated against the service perimeter's ingress rules, preventing data exfiltration. The DNS resolution and subsequent API call must originate from a context allowed by the perimeter, adding an extra layer of policy enforcement on top of IAM. This makes the DNS endpoint a secure choice for accessing sensitive clusters from trusted, defined environments.

Integrate DNS Resolution for Hybrid and Multi-Cloud Access

DNS-Based Endpoint for GKE Control Plane Access

A DNS-based endpoint provides access to the GKE control plane where the source of the traffic determines whether access is granted, rather than relying on IP address-based authorized networks. When you enable the DNS-based endpoint using the --enable-dns-access flag during cluster creation, the control plane becomes accessible from any network that can reach Google Cloud APIs, including on-premises data centers and other cloud provider networks. The DNS-based endpoint resolves to the control plane's private IP address, which can be configured with custom route advertisements to make the private endpoint reachable from on-premises environments through Cloud Router. Unlike IP-based endpoints that require you to specify authorized network CIDR ranges, the DNS-based endpoint lets you control access through IAM permissions, providing a more flexible and manageable security layer for organizations with dynamic infrastructure.

Cloud DNS for GKE Architecture

When Cloud DNS serves as the DNS provider for GKE, a controller pod runs on the control plane nodes and automatically syncs cluster DNS records into a managed private DNS zone. Pods send DNS queries to the Compute Engine metadata server at 169.254.169.254, which forwards cache misses to Cloud DNS for resolution. Cloud DNS supports the full Kubernetes DNS specification, providing resolution for A, AAAA, SRV, and PTR records for Services within a GKE cluster. This architecture removes the overhead of managing cluster-hosted DNS servers like kube-dns, because Cloud DNS is a fully managed service that requires no manual scaling, monitoring, or instance management. For optimal performance in large-scale clusters, you can enable NodeLocal DNSCache, which adds a caching layer directly on each node to reduce DNS query latency.

DNS Scopes for GKE Clusters

GKE supports three DNS scopes that determine where DNS resolution is available: cluster scope, VPC scope, and Cloud DNS additive VPC scope. In cluster scope, only nodes running within the GKE cluster can resolve service names, and service names do not conflict between clusters—this is the default behavior and matches how kube-dns operates. VPC scope extends DNS resolution to the entire VPC network, allowing resources like Compute Engine VMs to resolve GKE Service names, which is essential for hybrid architectures where workloads outside the cluster need to discover cluster services. The Cloud DNS additive VPC scope extends cluster scope to make headless Services resolvable from other resources in the VPC while maintaining the cluster-specific DNS zone. Choosing the appropriate scope depends on whether you need DNS resolution from resources outside the cluster; VPC scope is required when VMs or other clusters need to discover GKE Services.

Hybrid DNS Architecture with Cloud DNS

The recommended approach for hybrid environments uses two authoritative DNS systems: Cloud DNS handles authoritative resolution for your Google Cloud resources, while existing on-premises DNS servers handle on-premises resources. DNS forwarding between environments uses private zones and DNS server policies to route queries appropriately. In this setup, when an on-premises client needs to resolve a Google Cloud resource name, the query forwards to Cloud DNS through an inbound forwarder IP address in your VPC network. Conversely, when a GKE workload needs to resolve an on-premises hostname, Cloud DNS forwards the query to your on-premises DNS servers. This hybrid approach provides several advantages: it minimizes changes to existing business processes, lets you continue using established on-premises DNS tools, and allows you to maintain deny lists for filtering DNS requests on-premises while benefiting from Cloud DNS's managed infrastructure and logging capabilities.

DNS Forwarding and Private Zones

To enable DNS resolution between Google Cloud and on-premises environments, you configure forwarding rules that direct queries for specific domains to the appropriate DNS servers. A private zone in Cloud DNS hosts DNS records visible only within your organization, while a forwarding zone sends queries for specific domain suffixes to designated upstream name servers. For on-premises DNS resolution, you set up an inbound server policy in the VPC network that allocates IP addresses for on-premises DNS servers to forward queries, and you configure your on-premises DNS servers to forward requests for Google Cloud domains (such as gcp.example.com) to these inbound forwarder addresses. The private zone for Google Cloud resources (such as gcp.example.com) is created in the host project of a Shared VPC network, and a DNS server policy allows inbound DNS forwarding from on-premises networks. This setup requires that Cloud Router instances advertise the custom route for the IP address range 35.199.192.0/19, which contains the Cloud DNS forwarder addresses, to your on-premises environment.

DNS Peering Between VPC Networks

DNS peering allows one VPC network (the consumer) to resolve DNS records from another VPC network (the producer) without requiring a full VPC peering connection. In a hub-and-spoke topology, the hub VPC network hosts the DNS infrastructure, and spoke VPC networks peer their DNS zones to the hub. To set up this architecture, you create a private DNS zone for on-premises domains (such as corp.example.com) in the hub VPC and configure outbound forwarding to on-premises DNS servers. You then set DNS peering zones from the hub to each spoke for Google Cloud domains (such as projectX.gcp.example.com), and from each spoke to the hub for the root domain. This enables workloads in any spoke VPC to resolve both on-premises and cross-project Google Cloud resources through a centralized DNS hub. DNS peering is unidirectional, meaning each VPC network must set up a peering relationship to the other VPC network to enable bidirectional resolution.

Consistent Naming Standards

Creating a consistent naming standard across your organization is essential for managing DNS in hybrid and multi-cloud environments. You can choose from several patterns: using different domain names for each environment (such as corp.example.com for on-premises and gcp.example.com for Google Cloud), making the Google Cloud domain a subdomain of the on-premises domain (such as gcp.corp.example.com), or using the same domain for both environments (which is not recommended because it makes hybrid DNS management significantly more difficult). The preferred pattern uses separate domains for each environment, which allows clean forwarding of DNS queries between environments without namespace conflicts. For example, your organization might use example.com as the public domain, corp.example.com for on-premises resources hosted by your existing DNS servers, and gcp.example.com for resources in Google Cloud managed by Cloud DNS private zones.

Implement and Manage Public Endpoint Access Controls

Public Control Plane Access and Endpoints

A GKE control plane exposes interfaces through IP-based endpoints, DNS-based endpoints, or a combination of both. When an administrator enables a public IP-based endpoint during cluster creation, external clients communicate directly with the Kubernetes API server across the public internet. Even if public endpoint access is disabled for external users, Google retains management access through the public endpoint for automatic upgrades and scheduled maintenance. To determine the connectivity mode of an existing cluster, administrators inspect the cluster configuration using the Google Cloud CLI:

• Private cluster with VPC peering: The configuration resource contains an assigned peering name.
• Private cluster with Private Service Connect (PSC): The configuration resource has an assigned private endpoint and no peering name.
• Publicly accessible cluster: The configuration exposes public endpoints governed by authorized networks.

Securing Public Endpoints with Authorized Networks

Authorized networks restrict access to the GKE control plane by filtering traffic based on source IP address CIDR blocks. When authorized networks are enabled on a cluster with a public endpoint, only incoming requests originating from approved public or private IP ranges can connect to the API server. All traffic originating from unauthorized external IP addresses, as well as unauthorized Compute Engine virtual machines (VMs) or serverless workloads using Google external IPs, is automatically blocked. Cluster administrators can configure up to 50 authorized network CIDR ranges if the cluster does not utilize a private peering endpoint. By default, authorized networks permit internal communication between the cluster's Pods and nodes. For on-premises environments connecting to the control plane over hybrid connections, administrators configure custom route advertisements to ensure reachability across network boundaries.

Firewall Management and Subnet Expansion Dependencies

Google Cloud applies default ingress firewall rules at priority 1000 to permit essential control plane traffic between worker nodes and the kube-apiserver. Custom VPC firewall rules and hierarchical firewall policies apply at the VM node level and must not block default system communication, such as kubelet registration or telemetry Pods like event-exporter. When an administrator expands the primary IP address range of a subnet to support node scaling, a strict operational order must be followed:

1. Expand the subnet primary IP range in the VPC network.
2. Add the newly expanded primary IP address range to the cluster's authorized networks list immediately.
3. Allow the control plane to update its internal ingress-allow firewall rules.

If the expanded subnet range is omitted from the authorized networks configuration, the API server firewall rules will fail to update. As a consequence, newly provisioned nodes in the expanded address range cannot register with the control plane, causing node pool upgrades and liveness probe replacements to fail continuously in a replacement loop.

DNS-Based Endpoint Access Control

A DNS-based endpoint allows administrators to connect to the GKE control plane using source DNS resolution rather than fixed IP address whitelisting. By enabling the --enable-dns-access flag during cluster setup, the API server becomes reachable from any external, hybrid, or multi-VPC environment that can access Google Cloud APIs. This eliminates the operational requirement to deploy intermediate proxy nodes or bastion hosts to bridge non-transitive VPC Network Peering connections. DNS-based endpoints integrate directly with Identity and Access Management (IAM) to provide dynamic, policy-based identity controls over incoming traffic. In multi-cluster or hybrid topologies, administrators pair DNS-based access with Cloud DNS private zones or forwarding rules to provide secure, cross-environment name resolution. This configuration allows developers to safely manage public and hybrid clusters without exposing static control plane IP addresses to the broader public internet.

Key Facts

• A DNS-based endpoint for GKE control plane access uses IAM policies to control access instead of static IP address allow-lists, and is enabled with the --enable-dns-access flag during cluster creation.
• Private Google Access and VPC Service Controls work together with a DNS-based endpoint to keep control plane traffic within Google's network and prevent data exfiltration.
• Cloud DNS can serve as the DNS provider for GKE, automatically syncing cluster DNS records into a managed private zone and supporting the full Kubernetes DNS specification.
• When expanding a subnet's primary IP range, the new range must be added to the cluster's authorized networks list; otherwise, new nodes cannot register with the control plane.

Frequently Asked Questions

What is the difference between a DNS-based endpoint and an IP-based endpoint for GKE control plane access?

A DNS-based endpoint uses IAM policies to grant access based on the source of the traffic and does not require static IP address allow-lists, while an IP-based endpoint (authorized networks) restricts access to predefined CIDR ranges. The DNS-based endpoint is more flexible for dynamic environments and hybrid/multi-cloud scenarios.

When should I use DNS peering instead of VPC peering for DNS resolution?

DNS peering allows one VPC network to resolve DNS records from another VPC network without requiring a full VPC peering connection. Use DNS peering when you need centralized DNS resolution in a hub-and-spoke topology without the overhead of peering every spoke to each other.

What happens if I forget to add an expanded subnet range to the authorized networks list?

If the expanded subnet range is not added to the authorized networks list, the control plane's firewall rules will not update, and newly provisioned nodes in that range cannot register with the API server. This causes node pool upgrades and liveness probe replacements to fail continuously.