Google Kubernetes Engine (GKE) gives administrators the choice between public and private cluster nodes, and this choice affects how workloads connect to the internet and how secure the cluster is. Public nodes have external IP addresses and can communicate directly with the internet. Private nodes have only internal IP addresses and cannot be reached from the internet without special configuration. The decision between these two options impacts security, cost, connectivity to Google APIs, and how you manage network traffic for your applications.
Private cluster nodes are Compute Engine virtual machines that receive only internal IP addresses from the subnet's primary IP range and do not have external IP addresses. Public cluster nodes receive external IP addresses directly, which allows them to communicate with the internet if firewall rules permit it. In GKE Standard, you can configure private nodes at the cluster level or override settings at the individual node pool level. In GKE Autopilot, you configure privacy at the workload level instead.
Choosing private nodes improves security because workloads and virtual machines stay hidden from direct internet exposure. The GKE control plane still communicates with private worker nodes using internal IP addresses only. However, when you convert a public node pool to private, workloads lose their ability to reach the internet unless you set up translation or routing mechanisms like Cloud NAT.
Private Google Access (PGA) is a VPC feature that lets private nodes and Pods reach Google APIs and container registries without needing external IP addresses. Traffic using PGA stays inside Google's internal network instead of going across the public internet. When you create a private cluster, GKE automatically enables PGA on the subnet, except for clusters inside a Shared VPC where you must enable it manually.
Administrators can configure custom DNS zones to direct Google API traffic to specific internal IP ranges. Traffic can route to private.googleapis.com using the IP range 199.36.153.8/30 or to restricted.googleapis.com using 199.36.153.4/30 when using VPC Service Controls. Workloads authenticate securely using Workload Identity Federation for GKE, which connects Kubernetes service accounts directly to IAM permissions so Pods can query Google Cloud services without going through external egress gateways.
Cloud NAT provides outbound internet connectivity for private nodes and Pods without assigning them public IP addresses. When you configure Cloud NAT for a private GKE cluster, the gateway must cover both the primary subnet IP range used by nodes and the secondary IP ranges assigned to Pods and Services. In a Shared VPC environment, you must deploy the Cloud NAT gateway in the host project where the network lives.
GKE VPC-native clusters allocate alias IP ranges to nodes, so Cloud NAT allocates translation resources based on the underlying node VMs. In static port allocation, Cloud NAT reserves at least 1,024 ports per node VM. Dynamic port allocation adjusts between a configured minimum (such as 64 ports) and maximum (such as 2,048 ports) based on demand. To prevent port exhaustion during high connection churn, you can reduce the TCP TIME_WAIT timeout from 120 seconds to 5 seconds and enable the --disable-default-snat flag on GKE clusters.
Cloud Service Mesh provides standalone forward proxies called egress gateways to control, authorize, and observe outbound traffic leaving the cluster at the application layer. Traffic flows from the application container to an Envoy sidecar proxy, then across the internal network to a dedicated egress gateway proxy, and finally toward the external destination. This architecture separates application developer workflows from network security policies by enforcing Layer 7 authorization policies alongside Layer 4 transport controls.
To prevent workloads from bypassing egress controls, you should run egress gateways on a dedicated gateway node pool that is isolated from standard application workloads. You place taints on gateway nodes and add matching tolerations only to the egress gateway deployment, while using a node selector to direct proxy Pod placement. Restrictive VPC firewall rules applied to default node pools block direct outbound connections, while separate firewall rules permit egress traffic only from the dedicated gateway nodes.
Public cluster nodes assign ephemeral external IP addresses to node VMs, which creates challenges for traditional perimeter firewall policies. Because Pod and node IP addresses change during scaling and upgrades, tracking fixed IP identities on external firewall devices becomes difficult. To secure public nodes, you combine VPC firewall rules with Kubernetes network policies.
VPC firewall rules apply Layer 4 filtering to node VMs using service accounts or network tags, ensuring different node pools receive different network permissions. Inside the cluster, Kubernetes network policies or GKE Dataplane V2 enforce Layer 4 filtering at the Pod level using namespace and Pod labels to define allow and deny rules. A default-deny policy ensures newly deployed workloads cannot start unauthorized egress connections regardless of the node's public IP state.
Private nodes are GKE worker nodes that have only internal IP addresses and no direct inbound or outbound internet connectivity. This configuration enforces network isolation by removing a direct attack surface from the public internet. Workloads on these nodes cannot reach the internet unless you enable a NAT solution like Cloud NAT. The control plane communicates with all nodes using internal IPs only. This model supports zero-trust frameworks and strict regulatory compliance such as PCI DSS or GDPR by keeping sensitive data and workloads within a private network boundary.
Public nodes have external IP addresses, providing direct internet connectivity. This model requires strong security measures to manage the increased external exposure. You must implement strict VPC firewall rules and IAM policies to control inbound and outbound traffic. Without these additional layers, public nodes create a larger attack surface and make the cluster more vulnerable to external threats. This model works well for development environments or workloads that need low-latency direct internet egress.
The trade-off centers on connectivity versus isolation. Private nodes enhance security by default but add complexity for outbound traffic, requiring Cloud NAT for internet access and Private Google Access for Google APIs. Public nodes simplify connectivity but shift the security burden to perimeter controls. Private nodes can reduce costs by eliminating external IP charges for nodes that do not need them. However, converting a public node pool to private can break workloads if dependencies like Private Google Access or Cloud NAT are not set up first, especially in Shared VPC networks.
Choosing private nodes is a primary control for meeting compliance requirements that demand network isolation for sensitive workloads. To build defense-in-depth, you layer additional controls regardless of node type. This includes enabling GKE Dataplane V2 for built-in network policy enforcement and logging, applying Kubernetes network policies to restrict Pod-to-Pod communication, and using VPC Service Controls to create a service perimeter. For private clusters, you secure egress using dedicated egress gateways on hardened node pools and apply granular VPC firewall rules based on node service accounts or network tags.
A private GKE cluster has nodes with only internal IP addresses that are not connected to the internet by default. Private nodes cannot receive inbound traffic from the public internet, which significantly reduces the cluster's attack surface. You can enable private nodes at the cluster level or at the node pool level for Standard clusters, allowing you to mix public and private node pools within the same cluster. If you convert a public node pool to private, workloads that need external access may fail unless you configure Cloud NAT for outbound internet access or enable Private Google Access for Google APIs.
Public nodes have both internal and external IP addresses, allowing them to communicate with the internet directly. Public nodes work well for workloads that must be directly accessible from the internet or that need low-latency access to external services without NAT overhead. However, public nodes expose your workloads to potential external attacks, so you must weigh the accessibility benefit against the security risk for each workload.
You can associate different service accounts with different node pools, then configure VPC firewall rules to apply different Layer 4 controls to each node pool based on its service account or network tags. This approach lets you enforce stricter security on sensitive node pools while allowing more permissive access for workloads that need it. For example, you might allow external traffic only to a node pool running public-facing web servers while blocking all external traffic to a node pool running backend databases.
Kubernetes network policies provide additional isolation by controlling traffic at the Pod level rather than the node level. Network policies are scoped to namespaces and can be applied to specific Pods within a namespace, giving you finer-grained control over which Pods can communicate with each other and with external endpoints. When you apply a network policy to a namespace, all traffic that is not explicitly allowed by the policy is denied by default.
For clusters requiring controlled outbound access, you can deploy egress gateways on dedicated gateway node pools. The egress gateway acts as a single exit point for all traffic leaving the cluster, allowing consistent security policies, logging, and monitoring for outbound connections. You configure the egress gateway deployment with a node selector to ensure it runs only on nodes in the dedicated gateway node pool, and you use taints and tolerations to prevent other workloads from running on those nodes.
When using egress gateways, you should configure Cloud NAT to allow the gateway to make enough simultaneous connections to external destinations. Setting the minimum number of ports per VM appropriately helps avoid port exhaustion and connection reuse delays. Increasing the number of egress gateway replicas reduces the chances of endpoint-independent mapping conflicts, which occur when multiple connections compete for the same NAT mappings.
Private Google Access enables nodes and Pods on private clusters to access Google APIs and services using a set of four IP addresses without requiring external IP addresses. You can use either private.googleapis.com (199.36.153.8/30) or restricted.googleapis.com (199.36.153.4/30), depending on whether you are using VPC Service Controls. Traffic to these addresses never leaves the Google network, providing secure access to Google APIs without exposing workloads to the public internet.
Workload Identity is the recommended way to allow GKE workloads to authenticate with Google APIs. Instead of attaching service account keys to nodes or Pods, you bind a Kubernetes service account to a Google Cloud service account, following the principle of least privilege. When you use Workload Identity with Private Google Access, workload Pods can bypass the egress gateway and connect directly to Google APIs and services while maintaining security through IAM permissions.
Node pools support independent scaling through the cluster autoscaler, which dynamically adds and removes nodes based on workload demand. When planning for scaling, you must account for the maximum size of all node pools in your IP address planning, because each new node requires its own node IP address and its own allocatable set of Pod IP addresses. You can configure different Pods-per-node limits for different node pools, which affects IP address consumption and allows you to optimize allocation based on workload characteristics.
Node pool upgrades are managed separately from cluster control plane upgrades, letting you control when node software is updated. You can enable automatic node upgrades for each node pool, or you can manually upgrade nodes when needed. For node pools with specific security requirements such as gateway nodes, you may want to schedule upgrades during maintenance windows to minimize disruption to sensitive workloads.
When you convert a public node pool to private, workloads lose external connectivity unless you first configure Cloud NAT for outbound internet access and enable Private Google Access for Google APIs. In Shared VPC environments, you must manually enable Private Google Access on the host project. Workloads that depend on external services will fail until these connectivity mechanisms are in place.
Use public nodes for development workloads or applications that need low-latency direct internet access without the overhead of NAT translation. Public nodes simplify connectivity but require strong VPC firewall rules and IAM policies to manage the increased attack surface. Private nodes are preferred for production workloads with sensitive data or when compliance requirements mandate network isolation.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts