Automatically created firewall rules Stay organized with collections Save and categorize content based on your preferences.
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.
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:
| Name | Purpose | Source | Target (defines the destination) | Protocol and ports | Priority |
|---|---|---|---|---|---|
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 tag | TCP: 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:
| The node IP address range or a superset of this node IP address range:
| Node tag | TCP: 1-65535, UDP: 1-65535, ICMP | 1000 |
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 tag | TCP, UDP, SCTP, ICMP, ESP, AH | 1000 |
gke-[cluster-hash]-ipv6-all | Fordual-stack network clusters only. Permits traffic between nodes and Pods on a cluster. | Same IP address range allocated in | Node tag | TCP, UDP, SCTP, ICMP for IPv6, ESP, AH | 1000 |
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 tag | TCP: 10255 | 999 |
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 tag | TCP: 10255 | 1000 |
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.
| Name | Purpose | Source | Target (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 address | TCP 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. |
| LoadBalancer virtual IP address | TCP: 10256 |
k8s-[loadbalancer-hash]-http-hc | Permitshealth checks of an external passthrough Network Load Balancer Service whenexternalTrafficPolicy is set toLocal. |
| Node tag | TCP 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. |
| Node tag | TCP: 10256 |
[loadbalancer-hash]-hc | Permitshealth checks of an internal passthrough Network Load Balancer Service whenexternalTrafficPolicy is set toLocal. |
| Node tag | TCP 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: | 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 address | TCP 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: |
| LoadBalancer virtual IP address | TCP 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: |
| Node tag | TCP: 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 addresses | Node tag | TCP, UDP, SCTP, ICMP, ESP, AH |
GKE Gateway firewall rules
GKE creates the following Gateway firewall rules when creating aGateway andHTTPRoute resources:
| Name | Purpose | Source | Target (defines the destination) | Protocol and ports |
|---|---|---|---|---|
| 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 tag | TCP: all container target ports (for NEGs) |
GKE Ingress firewall rules
GKE creates the following Ingress firewall rules when creating anIngress resource:
| Name | Purpose | Source | Target (defines the destination) | Protocol and ports |
|---|---|---|---|---|
k8s-fw-l7-[random-hash] | Permitshealth checks of a 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. |
| Node tag | TCP: 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:
- Internal LoadBalancer Services using GKE subsetting
- Backend service-based external LoadBalancer Services
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
- Read an overview ofnetworking in GKE.
- Learn aboutConfiguring network policies for applications.
- Learn about otherPre-populated firewall rulesin Google Cloud.
- Learn more aboutCreating firewall rulesin projects that use Shared VPC.
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.