A VPC network path defines the route traffic takes from its source to its destination. For combined services using Cloud Load Balancing and GKE, the path typically starts from an external user or an internal service, passes through the load balancer, and is then directed to Pods within a GKE cluster. To ensure security inspection, this path must be configured so that traffic flows through a Cloud NGFW policy before reaching the backend workloads. This requires placing the NGFW in-line with the traffic flow, often by associating firewall policies with the VPC networks or subnets that carry the traffic between these components.
Firewall rule precedence determines the order in which different policies are evaluated. In Google Cloud, the hierarchy is: Hierarchical Firewall Policies at the organization and folder level are evaluated first, then Global Network Firewall Policies at the network level, and finally VPC Firewall Rules at the subnet and VM level. When combining services, a Cloud NGFW policy is applied as a Global Network Firewall Policy. Traffic matching an NGFW rule with an apply_security_profile_group action is redirected for inspection before lower-priority VPC firewall rules are considered. This ensures threats are filtered by the NGFW before the traffic is permitted or denied by standard ingress/egress rules.
For traffic flowing to GKE workloads exposed via a load balancer, the policy hierarchy must be explicitly configured. The load balancer's forwarding rule directs traffic to a backend service, which targets a Network Endpoint Group (NEG) containing GKE Pods. A Global Network Firewall Policy containing the NGFW rule must be associated with the VPC network hosting both the load balancer's proxy subnet and the GKE cluster's subnet. This association ensures traffic from the load balancer to the Pods is subject to NGFW inspection. The firewall policy rule must specify the NGFW security profile group and use the apply_security_profile_group action.
The traffic flow and security boundaries are defined by the resources and their network placements. The Cloud Load Balancer operates in a proxy-only subnet, which is a distinct boundary. Traffic from the internet or other VPCs enters this subnet. A firewall policy applied to the VPC network enforces that traffic destined for the GKE cluster's Pod IP range must be inspected. The trust boundary shifts at the NGFW; traffic deemed clean by the NGFW's threat prevention and URL filtering profiles is then allowed to proceed to the Pods based on subsequent VPC firewall rules, which should be configured to allow the inspected traffic.
Packet inspection rules in a firewall policy use the apply_security_profile_group action to intercept network packets and forward them to a packet inspection service. A rule directing traffic to packet inspection must reference a security profile group containing a configured security profile. Global network firewall policies can reference both organization-level and project-level security profile groups, whereas hierarchical firewall policies can only reference organization-level security profile groups. When a network packet matches the rule criteria, the firewall applies the referenced security profile group instead of simply allowing or denying the connection.
A security profile must reference the same intercept endpoint group that is associated with the target VPC networks where traffic inspection is required. For the rules to take effect, the containing firewall policy must be explicitly associated with the VPC networks carrying the traffic. In a global network firewall policy, administrators associate the policy directly with the target VPC networks. In a hierarchical network firewall policy, the policy is associated with an organization or folder resource, and any targeted network resources must include the specific VPC networks handling the workload.
Kubernetes network policies control traffic between pods within a GKE cluster by using the NetworkPolicy API. A network policy selects pods based on labels and defines rules that specify which ingress or egress traffic is allowed. When the first network policy is created in a namespace, all traffic that is not explicitly allowed by that policy is denied by default. GKE Dataplane V2, which is based on eBPF, provides built-in network policy enforcement without requiring a separate CNI plugin. You enable network policies when creating a cluster with the --enable-network-policy flag, or you can enable them on an existing cluster, though this causes cluster nodes to restart.
VPC firewall rules operate at the virtual machine level, controlling traffic to and from the nodes that host GKE pods. These rules work together with Kubernetes network policies to provide defense-in-depth, where VPC firewalls handle node-level traffic and network policies handle pod-level traffic. GKE automatically creates default firewall rules for essential operations, such as allowing the control plane to communicate with nodes, but you can create custom rules to meet specific security requirements. When applying egress firewall rules to nodes, be cautious because rules that are too restrictive can break features like NodePort and kubectl exec.
GKE Dataplane V2 is a networking layer that uses eBPF programs to handle service routing, network policy enforcement, and logging. When you create a cluster with Dataplane V2, you do not need to explicitly enable network policies because the dataplane manages enforcement automatically. The dataplane also supports network policy logging through a NetworkLogging custom resource definition, which lets you record allowed and denied connections for security auditing. Enable Dataplane V2 using the --enable-dataplane-v2 flag when creating a cluster.
Cloud NAT provides network address translation for GKE clusters with private nodes, allowing pods to reach the internet without public IP addresses. In private clusters, pods cannot access the internet by default, so Cloud NAT translates their private IP addresses to a public IP when sending traffic outward. Configure Cloud NAT for the primary and secondary ranges used by your GKE subnet, and ensure you allocate enough ports per VM to avoid connection exhaustion. You should avoid double SNAT, where traffic is translated first at the GKE node and again by Cloud NAT, unless you specifically need to hide pod IP addresses from on-premises networks connected through Cloud VPN or Cloud Interconnect.
Private Google Access lets private GKE nodes and pods reach Google APIs and services without traversing the public internet. When enabled, traffic to Google APIs uses a set of four IP addresses that are reachable from your VPC network, so pods do not need 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. Private Google Access is enabled by default in clusters with private nodes, except for Shared VPC clusters.
Google Cloud Armor security policies protect applications that use external Application Load Balancers from DDoS attacks and web-based threats. In GKE, you enable Cloud Armor by adding a security policy to a BackendConfig that is attached to an Ingress object. This allows Cloud Armor to inspect and filter traffic at the network edge before it reaches your cluster. Cloud Armor can be combined with Identity-Aware Proxy (IAP) for additional authentication layers, where IAP verifies user identity before allowing access to applications.
Container-native load balancing reduces network hops and latency by directing traffic directly to pods rather than to nodes. When you expose services using HTTP(S) externally, container-native load balancing allows for more exact traffic distribution and increases visibility in round-trip times. This type of load balancing also lets you use Cloud Armor security features with your GKE workloads. Choose container-native load balancing when you need lower latency and better traffic distribution for your applications.
When configuring GKE services, you can control external access at the load balancer level. For services exposed through a LoadBalancer type, use the loadBalancerSourceRanges field to restrict access to specific IP address ranges. For Ingress resources, combine network policies with Cloud Armor and IAP to create multiple security layers. The Kubernetes Service manifest defines which pods receive traffic through the selector field, and the service type determines whether traffic is internal, external, or routed through a cloud load balancer.
StudyCerts
StudyCertsapply_security_profile_group action in firewall rules to redirect traffic for inspection before lower-priority VPC firewall rules are evaluated.Kubernetes network policies control traffic at the pod level within a GKE cluster, while VPC firewall rules control traffic at the virtual machine level that hosts the nodes. These two layers work together for defense-in-depth, with VPC firewalls handling node-level traffic and network policies handling pod-level traffic.
Avoid double SNAT, where traffic is translated first at the GKE node and again by Cloud NAT, unless you specifically need to hide pod IP addresses from on-premises networks connected through Cloud VPN or Cloud Interconnect. Double SNAT can cause connection issues and unnecessary complexity.
apply_security_profile_group action in firewall rules?The apply_security_profile_group action intercepts network packets and redirects them to a packet inspection service for threat evaluation. Instead of simply allowing or denying the connection, the firewall applies the referenced security profile group to inspect the traffic for threats before deciding whether to permit it.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills