Professional Cloud Network Engineer
Kubernetes NetworkPolicy resources let you configure network access rules for pods using label-based selectors to define which workloads the policies apply to. A NetworkPolicy can control Ingress (incoming), Egress (outgoing), or both types of traffic by specifying the source pods that can connect to selected pods and the destination pods that selected pods can reach. Traffic enforcement occurs at the node level using a 5-tuple connection model that includes source IP, destination IP, source port, destination port, and protocol (TCP or UDP). When you create a NetworkPolicy, enforcement happens at the node hosting the source workload for outbound traffic and at the node hosting the destination workload for inbound traffic, meaning both directions must be explicitly allowed for a connection to succeed. The policy model uses additive allow rules where multiple policies applied to a workload combine into an "any match" result, allowing traffic if it matches at least one rule; there are no explicit deny rules. Reply traffic such as SYN-ACK segments is not subject to enforcement since it is automatically allowed when the initiating traffic is permitted.
To use network policies in GKE, your cluster must use GKE Dataplane V2, which provides the underlying network enforcement capabilities. You enable network policy enforcement when creating a cluster or by updating an existing cluster's network configuration. Once enabled, network policies control pod-to-pod traffic using firewall rules at the pod level, allowing fine-grained control over which workloads can communicate within the cluster. When configuring ingress policies, you specify which source pods can connect to target pods using pod selectors with matching labels. For example, a policy can allow traffic to pods with the label app:hello only from pods with the label app:foo, blocking all other incoming traffic including external traffic and traffic from pods in other namespaces. Egress policies work similarly but control outbound traffic, requiring you to explicitly allow DNS resolution (port 53 over TCP and UDP) if workloads need to resolve internal or external hostnames.
Gatekeeper is an admission controller that validates requests to create and update pods using the Open Policy Agent (OPA) framework, providing an additional layer of security beyond network policies. Gatekeeper allows administrators to define constraints that specify conditions permitting or denying deployment behaviors, and constraint templates that provide the reusable Rego logic for evaluating Kubernetes object fields. This enables organizations to enforce security requirements such as restricting privileged containers, requiring specific security contexts, and controlling resource allocations at deployment time. Gatekeeper supports gradual policy rollout through dry-run modes, allowing administrators to test policy impact before enforcement, and audit capabilities that check existing workloads against defined policies. You enable Gatekeeper on a GKE cluster through the Policy Controller add-on, which deploys the admission webhook infrastructure needed to intercept and evaluate pod creation and modification requests against your defined constraints.
Multi-network network policies extend standard Kubernetes network policies by applying them to specific pod networks within a cluster that has multi networking enabled. These policies control traffic using firewall rules at the pod level and manage traffic flow between pods and services across different network interfaces. To use multi-network network policies, you must create a cluster with multi-network support enabled, create node pools and pod networks, reference the pod network in your policy, and create network policies that reference the same pod network utilized by your workload. The requirements for multi-network network policies include Google Cloud CLI version 459 or later, GKE cluster versions 1.28.5-gke.1293000 or later (or 1.29.0-gke.1484000 or later), and GKE Dataplane V2 enabled on the cluster. It's important to note that FQDN network policies and CiliumClusterWide network policies are not supported on pods connected to multiple networks, as these policies would affect all pod connections including those where the policies aren't intended to apply.
Namespace isolation in GKE involves using network policies to segment application traffic and control communication between workloads in different namespaces. You can implement default deny-all policies that block all traffic to pods in a namespace, then selectively allow only the specific traffic paths required for your applications to function. This approach follows the principle of least privilege by starting with restrictive policies and adding exceptions as needed. When implementing namespace isolation, you create NetworkPolicy resources with namespace selectors that match specific namespaces by label, or use pod selectors that target workloads by their labels within a namespace. For more granular control, you can create workload-level policies that define communication between individual workloads using label-based selectors, allowing you to restrict traffic to specific source-destination pairs rather than permitting all traffic within a namespace. This granularity improves security by limiting the blast radius of potential compromises and ensures that workloads can only communicate through explicitly defined paths.
A Kubernetes NetworkPolicy is a specification that defines how groups of Pods are allowed to communicate with each other and with other network endpoints. It acts as a Pod-level firewall, using labels to select specific Pods and defining rules for allowed ingress (incoming) and egress (outgoing) traffic. By default, all Pods in a cluster can communicate freely; the first NetworkPolicy created in a namespace changes this to a default-deny model, where only traffic explicitly allowed by a policy is permitted. This enforces the principle of least privilege and helps prevent lateral movement if a Pod is compromised. Network policies work alongside broader Google Cloud security layers like VPC firewall rules and service perimeters to create defense-in-depth security.
To use NetworkPolicy resources, you must enable network policy enforcement on your GKE cluster. For new clusters, you enable this by using the --enable-network-policy flag with the gcloud container clusters create command. For modern clusters, it is recommended to use GKE Dataplane V2, which is enabled by default in Autopilot clusters and can be enabled in Standard clusters with the --enable-dataplane-v2 flag. GKE Dataplane V2 provides integrated network policy enforcement, logging, and observability without requiring a separate Container Network Interface (CNI) plugin like Calico. When you create a NetworkPolicy, you define the podSelector to choose the target Pods and then specify ingress and/or egress rules that can allow traffic from other Pods (selected by their labels), namespaces, or specific IP blocks (ipBlock).
Network policies and VPC firewall rules operate at different layers but are designed to work together. VPC firewall rules apply at the virtual machine (node) level, controlling traffic to and from the cluster nodes based on IP addresses, ports, and protocols. In contrast, NetworkPolicy resources apply at the Pod level, controlling traffic between Pods based on Kubernetes labels. This creates a layered security model: VPC firewalls define the external perimeter of the cluster (north-south traffic), while network policies define the internal segmentation (east-west traffic). When designing policies, you must ensure they do not conflict; for example, a VPC firewall rule blocking a port must be considered if a network policy expects traffic on that port to reach a Pod from outside the cluster.
For network policies to function correctly, proper IP address planning for Pods and Services is essential. GKE uses a native CNI in VPC-native clusters, where Pods receive IP addresses from a secondary alias IP range within the VPC subnet. These Pod IPs are natively routable within the VPC. When writing network policy rules that use ipBlock selectors to allow or deny traffic from specific CIDR ranges, you must include the cluster's Pod and Service IP ranges if the traffic originates from or is destined to those internal ranges. The behavior of ipBlock rules can differ between GKE Dataplane V2 and the Calico CNI plugin, so testing policy application is necessary to ensure expected behavior.
Several operational factors affect the integration of network policies. The externalTrafficPolicy setting on a Kubernetes Service (Local vs. Cluster) influences whether the source IP address seen by a Pod is the original client IP or the node IP, which impacts how ipBlock rules in network policies are written. Furthermore, enabling network policies on an existing cluster requires a node restart, which can cause a temporary disruption. For high-security environments, combining network policies with service meshes like Cloud Service Mesh (for Layer 7 controls) and VPC Service Controls (for data perimeter security) provides a comprehensive security posture. The trade-off is increased complexity in management and troubleshooting, which can be mitigated by using tools like network policy logging in GKE Dataplane V2 to monitor allowed and denied connections.
Network policy enforcement is an additive, allow-based model that evaluates connection attempts using standard 5-tuple attributes: source IP address, destination IP address, source port, destination port, and protocol. When a policy selects a workload, that workload enters an isolated state where any traffic not explicitly permitted by an allow rule is dropped. Enforcement of outbound traffic occurs on the node hosting the source workload, while enforcement of inbound traffic occurs when packets arrive at the node hosting the destination workload. Because network policy enforcement is stateful, connection tracking automatically permits reply traffic, such as a TCP SYN-ACK segment, without requiring a separate reverse rule. When a network policy blocks a connection attempt, the packet is silently discarded at either the source or destination node, causing the initiating client to observe a connection timeout rather than an explicit connection reset or protocol rejection. Multiple network policies applied to the same Pod combine into a single union, meaning traffic is allowed if it matches at least one defined rule across all active policies.
An Ingress network policy restricts incoming traffic to a selected group of Pods by evaluating the source and destination of each incoming request. The policy uses a podSelector to designate the target workloads and an ingress.from block to specify the allowed origin workloads using label selectors. Any incoming traffic from unselected Pods, external endpoints, or other namespaces that do not match the rule criteria is automatically blocked. In a typical configuration, traffic flows successfully only when a request originates from a Pod with a specific label (such as app=foo) to the destination Pod with a matching label (such as app=hello). If a client Pod with a different label attempts to communicate with the protected workload, the network policy discards the packets at the destination node. This isolation boundary prevents unauthorized workloads within the same cluster from reaching protected backend services.
An Egress network policy restricts outbound traffic leaving a designated Pod by specifying allowed destinations in an egress.to rule. When an administrator restricts egress traffic, the policy must explicitly permit Domain Name System (DNS) traffic so the workload can resolve internal and external hostnames. DNS resolution requires explicitly opening port 53 for both TCP and UDP protocols to avoid query timeouts. This egress policy applies directly to workloads with a specific label and limits their outbound communication to Pods with matching destination labels. By including port 53 across UDP and TCP in the ruleset, the workload retains the ability to resolve names through the cluster DNS service while remaining blocked from accessing any other arbitrary internal or external network destinations. Without this explicit DNS permission, name resolution fails and the workload cannot function properly even for allowed destinations.
Multi-network network policies extend traffic filtering rules to clusters where Pods attach to multiple network interfaces. To enforce network policies in multi-network environments, clusters require GKE Dataplane V2, Google Cloud CLI (gcloud CLI) version 459 or later, and GKE version 1.28.5-gke.1293000 or 1.29.0-gke.1484000 or later. Workloads attach to designated Pod networks using annotations, and applied network policies must reference the specific Pod network utilized by the workload. Administrators must account for specific limitations when designing multi-network security rules. Fully Qualified Domain Name (FQDN) network policies and CiliumClusterWide network policies are not fully supported on multi-network workloads; applying them to a Pod with multiple network interfaces affects all of that Pod's connections, including secondary networks where the policy was not intended to apply. Careful policy design ensures that firewall rules align precisely with the intended network interface without inadvertently restricting auxiliary traffic paths.
VPC firewall rules control traffic at the virtual machine (node) level based on IP addresses, ports, and protocols, while NetworkPolicy resources control traffic between Pods based on Kubernetes labels. VPC firewalls handle north-south traffic (traffic entering and leaving the cluster), and network policies handle east-west traffic (traffic between pods within the cluster).
When you restrict egress traffic with a network policy, all outbound traffic is blocked by default except reply traffic for established connections. DNS resolution uses port 53 over TCP and UDP, which is not related to any existing connection, so it must be explicitly allowed in the egress policy rules. Without this permission, workloads cannot resolve internal or external hostnames.
Multiple network policies applied to the same Pod combine into a single union using an "any match" model. This means traffic is allowed if it matches at least one rule in any of the applied policies. There are no explicit deny rules in the network policy model.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts