Automatically created firewall rules

This page describes the ingress allowVPC firewallrules that Google Kubernetes Engine (GKE) by default createsautomatically in Google Cloud.

Applicable firewalls and egress firewalls

GKE uses Virtual Private Cloud (VPC) firewall rules to controlincoming and outgoing traffic to your Pods and nodes. By default,GKE automatically creates and manages certain firewall rules toallow essential traffic, such as communication between nodes and Pods, andtraffic to your Kubernetes control plane. While GKE automaticallycreates ingress allow VPC firewall rules for LoadBalancerServices by default, you can disable this behavior to manage firewall rules orpolicies manually or utilize advanced firewall features.

Ingress allow firewall rules created by GKE aren't theonly applicable firewall rules that apply to nodes in a cluster. Thecomplete set of applicable firewall rules for ingress and egress isdefined from rules inhierarchical firewallpolicies,global network firewallpolicies,regional networkfirewall policies, andother VPC firewall rules.

Best practice:

Plan and design theconfiguration for your cluster, workloads and Services with your organization'sNetwork administrators and Security engineers, and understand the firewallpolicy andrule evaluation order so you know which firewall rules take precedence.

GKE only createsingressVPC firewallrules because GKE relies ontheimplied allowed egress lowest-priority firewallrule.

If you've configured egress deny firewall rules in your cluster'sVPC network, you might have to create egress allow rules topermit communication between nodes, Pods, and the cluster's control plane.For example, if you've created an egress deny firewall rule for all protocolsand ports and all destination IP addresses, you must create egress allowfirewall rules in addition to the ingress rules that GKEcreates automatically. Connectivity to control plane endpoints always usesTCP destination port443, but connectivity among nodes and Pods of thecluster can use any protocol and destination port.

The following tools are useful to determine which firewall rules allow ordeny traffic:

Firewall rules

GKE by default creates firewall rules automatically when creatingthe following resources:

  • GKE clusters
  • GKE Services
  • GKE Gateways and HTTPRoutes
  • GKE Ingresses

Unless otherwise specified, the priority for all automaticallycreated firewall rules is 1000, which is thedefault value for firewall rules.If you would like more control over firewall behavior, you can create firewallrules with a higherpriority.Firewall rules with a higher priority are appliedbefore automatically created firewall rules.

Warning: Don't modify or delete firewall rules created by GKE.Any manual changes to these rules might be reverted, which could lead tounexpected behavior in your clusters.Note: Evaluate all firewall rules applicable to the VM instances within aVPC, both ingress and egress. If you decide to block egressconnections for clusters, you must ensure that appropriate firewallrules exist to allow nodes to communicate with the control plane on TCP port443. If you are usingKonnectivity proxy and blocking all egress traffic, ensurethere is a rule with higher priority that allows traffic on port 8132.

GKE cluster firewall rules

GKE creates the following ingress firewall rules when creating acluster:

NamePurposeSourceTarget (defines the destination)Protocol and portsPriority
gke-[cluster-name]-[cluster-hash]-master For Autopilot and Standard clusters that rely on VPC Network Peering for control plane private endpoint connectivity. Permits the control plane to access the kubelet and metrics-server on cluster nodes.Control plane IP address range (/28)Node tagTCP: 443 (metrics-server) and TCP: 10250 (kubelet)1000
gke-[cluster-name]-[cluster-hash]-vms

Used for intra-cluster communication required by theKubernetes networking model. Allows software running on nodes to send packets, with sources matching node IP addresses, to destination Pod IP and node IP addresses in the cluster. For example, traffic allowed by this rule includes:

  • Packets sent from system daemons, such as kubelet, to node and Pod IP address destinations of the cluster.
  • Packets sent from software running in Pods withhostNetwork:true to node and Pod IP address destinations of the cluster.
The node IP address range or a superset of this node IP address range:
  • For auto mode VPC networks, GKE uses the10.128.0.0/9 CIDR because that range includes all current and future subnet primary IPv4 address ranges for the automatically created subnetworks.
  • For custom mode VPC networks, GKE uses the primary IPv4 address range of the cluster's subnet.
GKE doesnot update the source IPv4 range of this firewall rule if you expand the primary IPv4 range of the cluster's subnet. You mustcreate the necessary ingress firewall rule manually if you expand the primary IPv4 range of the cluster's subnet.
Node tagTCP: 1-65535, UDP: 1-65535, ICMP1000
gke-[cluster-name]-[cluster-hash]-all Permits traffic between all Pods on a cluster, as required by theKubernetes networking model.

Pod CIDR

For clusters with discontiguous multi-Pod CIDR enabled, all Pod CIDR blocks used by the cluster.

Node tagTCP, UDP, SCTP, ICMP, ESP, AH1000
gke-[cluster-hash]-ipv6-all Fordual-stack network clusters only. Permits traffic between nodes and Pods on a cluster.

Same IP address range allocated insubnetIpv6CidrBlock.

Node tagTCP, UDP, SCTP, ICMP for IPv6, ESP, AH1000
gke-[cluster-name]-[cluster-hash]-inkubelet Allow access to port 10255 (Kubelet read-only port) from internal Pod CIDRs and Node CIDRs in new GKE clusters running version 1.23.6 or later. Clusters running versions later than 1.26.4-gke.500 use the Kubelet authenticated port (10250) instead. Don't add firewall rules blocking 10250 within the cluster.

Internal Pod CIDRs and Node CIDRs.

Node tagTCP: 10255999
gke-[cluster-name]-[cluster-hash]-exkubelet Deny public access to port 10255 in new GKE clusters running version 1.23.6 or later.

0.0.0.0/0

Node tagTCP: 102551000

GKE Service firewall rules

GKE creates the following ingress firewall rules when creating aService. You can prevent some ofthese firewall rules from being created bymanaging VPCfirewall rules creation.

NamePurposeSourceTarget (defines the destination)Protocol and ports
k8s-fw-[loadbalancer-hash]Permits ingress traffic to reach a Service.Source comes fromspec.loadBalancerSourceRanges. Defaults to0.0.0.0/0 ifspec.loadBalancerSourceRanges is omitted.

For more details, seeFirewall rules and source IP address allowlist.

LoadBalancer virtual IP addressTCP and UDP on the ports specified in the Service manifest.
k8s-[cluster-id]-node-http-hc Permitshealth checks of an external passthrough Network Load Balancer Service whenexternalTrafficPolicy is set toCluster.
  • 35.191.0.0/16
  • 130.211.0.0/22
  • 209.85.152.0/22
  • 209.85.204.0/22
LoadBalancer virtual IP addressTCP: 10256
k8s-[loadbalancer-hash]-http-hc Permitshealth checks of an external passthrough Network Load Balancer Service whenexternalTrafficPolicy is set toLocal.
  • 35.191.0.0/16
  • 130.211.0.0/22
  • 209.85.152.0/22
  • 209.85.204.0/22
Node tagTCP port defined byspec.healthCheckNodePort. If unspecified, the Kubernetes control plane assigns a health check port from the node port range.

For more details, seeHealth check port.

k8s-[cluster-id]-node-hc Permitshealth checks of an internal passthrough Network Load Balancer Service whenexternalTrafficPolicy is set toCluster.
  • 35.191.0.0/16
  • 130.211.0.0/22
  • 209.85.152.0/22
  • 209.85.204.0/22
Node tagTCP: 10256
[loadbalancer-hash]-hc Permitshealth checks of an internal passthrough Network Load Balancer Service whenexternalTrafficPolicy is set toLocal.
  • 35.191.0.0/16
  • 130.211.0.0/22
  • 209.85.152.0/22
  • 209.85.204.0/22
Node tagTCP port defined byspec.healthCheckNodePort. If unspecified, the Kubernetes control plane assigns a health check port from the node port range.

For more details, seeHealth check port.

k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash] Permits ingress traffic to reach a Service when one of the following is enabled:
  • GKE subsetting.
  • Backend service-based external passthrough Network Load Balancer.
  • You can disable the automatic creation of these VPC firewall rules. For more information, seeManage automatic firewall rule creation.
  • Source comes fromspec.loadBalancerSourceRanges. Defaults to0.0.0.0/0 ifspec.loadBalancerSourceRanges is omitted.

    For more details, seeFirewall rules and source IP address allowlist.

    LoadBalancer virtual IP addressTCP and UDP on the ports specified in the Service manifest.
    k8s2-[cluster-id]-[namespace]-[service-name]-[suffixhash]-fw Permitshealth checks of the Service whenexternalTrafficPolicy is set toLocal and any of the following are enabled:
  • GKE subsetting.
  • Backend service-based external passthrough Network Load Balancer.
    • 35.191.0.0/16
    • 130.211.0.0/22
    • 209.85.152.0/22
    • 209.85.204.0/22
    LoadBalancer virtual IP addressTCP port defined byspec.healthCheckNodePort. If unspecified, the Kubernetes control plane assigns a health check port from the node port range.

    For more details, seeHealth check port.

    k8s2-[cluster-id]-l4-shared-hc-fw Permitshealth checks of the Service whenexternalTrafficPolicy is set toCluster and any of the following are enabled:
  • GKE subsetting.
  • Backend service-based external passthrough Network Load Balancer.
    • 35.191.0.0/16
    • 130.211.0.0/22
    • 209.85.152.0/22
    • 209.85.204.0/22
    Node tagTCP: 10256
    gke-[cluster-name]-[cluster-hash]-mcsd Permits the control plane to access the kubelet and metrics-server on cluster nodes for Multi-cluster Services. This rule has a priority of 900. Health check IP addressesNode tagTCP, UDP, SCTP, ICMP, ESP, AH

    GKE Gateway firewall rules

    GKE creates the following Gateway firewall rules when creating aGateway andHTTPRoute resources:

    NamePurposeSourceTarget (defines the destination)Protocol and ports
    • gkegw1-l7-[network]-[region/global]
    • gkemcg1-l7-[network]-[region/global]

    Permitshealth checks of anetwork endpoint group (NEG).

    The Gateway controller creates this rule when the first Gateway resource is created. The Gateway controller can update this rule if more Gateway resources are created.

    Node tagTCP: all container target ports (for NEGs)

    GKE Ingress firewall rules

    GKE creates the following Ingress firewall rules when creating anIngress resource:

    NamePurposeSourceTarget (defines the destination)Protocol and ports
    k8s-fw-l7-[random-hash]

    Permitshealth checks of aNodePort Service ornetwork endpoint group (NEG).

    The Ingress controller creates this rule when the first Ingress resource is created. The Ingress controller can update this rule if more Ingress resources are created.

    For GKE v1.17.13-gke.2600 or later:
    • 35.191.0.0/16
    • 130.211.0.0/22
    • User-defined proxy-only subnet ranges (for internal Application Load Balancers)
    Node tagTCP: 30000-32767, TCP:80 (for internal Application Load Balancers), TCP: all container target ports (for NEGs)

    Manage VPC firewall rules creation

    By default, GKE automatically creates ingress allow VPCfirewall rules for all LoadBalancer Services. If you want to manage firewall rulesfor LoadBalancer Services yourself, you must disable the automatic creation ofVPC firewall rules.

    Disabling the automatic creation of VPC firewall rules for LoadBalancerServices only applies to the following:

    For information on how to disable firewall rules, seeUser-managed firewallrules for GKE LoadBalancerServices.

    Shared VPC

    If you're using Ingress or LoadBalancer Services, and you have a cluster that islocated in a Shared VPC using a Shared VPC network, theGKE service account in the service project can't create and updateingress allow firewall rules in the host project. You can grant theGKE service account in a service project permissions to createand manage the firewall resources. For more information, seeShared VPC.

    Note: In case of GKE Gateway, the firewall rules are notautomatically deployed. You need to manually create the firewall rules in orderfor health checks to succeed.

    Required firewall rule for expanded subnet

    If youexpand the primary IPv4 range of the cluster's subnet,GKE does not automatically update the source range of thegke-[cluster-name]-[cluster-hash]-vms firewall rule. Because nodes in thecluster can receive IPv4 addresses from the expanded portion of the subnet'sprimary IPv4 range, you must manually create a firewall rule to allowcommunication between nodes of the cluster.

    The ingress firewall rule you must create must allow TCP and ICMP packetsfromthe expanded primary subnet IPv4 source range, and it must at least apply toall nodes in the cluster.

    To create an ingress firewall rule that only applies to the cluster's nodes,set the firewall rule's target to the same target tag used by your cluster'sautomatically-createdgke-[cluster-name]-[cluster-hash]-vms firewall rule.

    What's next

    Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

    Last updated 2025-12-15 UTC.