Network Policies
1. Network Policies
By default, all Pods can communicate with one another. However, what if access to certain Pods must be restricted? The solution is to implement a network policy. A network policy is a set of firewall rules applied at the Pod level that restrict access to other Pods and Services inside the cluster. For example, in a multi-layered application, network policies can be used to restrict access at each stack level. A web layer could only be accessed from a certain Service, and an application layer beneath this could only be accessed from the web layer. This effectively promotes defense in depth. So, why should you consider using network policies? Imagine an attacker compromised one of your Pods by exploiting a security vulnerability in it. Just by gaining access, an attacker would have the power to probe outwards from the compromised Pod to all other Pods in your cluster. And they might even find other vulnerabilities. As a result, it would be wise to limit the attack surface of your cluster. While network policies can be complex to manage, GKE Dataplane V2 simplifies the process with built-in policy enforcement, eliminating extra overhead. Autopilot clusters in GKE come with Dataplane V2 enabled by default, simplifying network policy management. For standard clusters, you can manually enable Dataplane V2 and take advantage of its streamlined network policies, provided your cluster meets the minimum requirements. GKE Dataplane V2 leverages eBPF, a powerful technology that operates within the Linux kernel. As packets arrive at a GKE node, GKE Dataplane V2 decides how to route and process the packets. Crucially, Dataplane V2 taps into Kubernetes-specific metadata embedded in these packets. This enables efficient packet processing and provides detailed, annotated logs for comprehensive network visibility. After you enable network policy enforcement for your cluster, you need to define the actual network policy. Enabling network policy enforcement consumes additional resources in nodes. This means that you might need to increase your cluster’s size to keep your scheduled workloads running. Network Policies are written in YAML files and have the kind NetworkPolicy. The podSelector lets you select a set of Pods based on labels. If “podSelector” isn’t provided, or is empty, the networking policy will be applied to all Pods in the namespace. policyTypes indicates whether ingress, egress, or both traffic restrictions will be applied. If policyTypes is left empty, a default ingress policy will apply automatically, and an egress policy won’t be specified. In the Ingress section of the policy, there are two main sections: “from” and “ports.” The “from” section can be from three sources: ipBlock, namespaceSelector, or podSelector. The “ports” section states what ports ingress will be accepted from. The combination of these two elements defines where traffic is allowed to enter the network. In the Egress section of the policy, there are two main sections: “to” and “ports.” In the example, traffic destined for network 10.0.0.0/24 on TCP port 5978 will be permitted to egress from the demo-app Pods. Remember, applying network policies does nothing if you haven’t enabled network policy on your cluster. You can use the “gcloud container clusters update” command to disable a network policy. In the Google Cloud console, disabling a network policy is a two-step process. You first disable the network policy for nodes, and then you disable the network policy for the control plane. If no network policies exist, all ingress and egress traffic will be allowed between the Pods in the namespace regardless of whether network policy enforcement is enabled or disabled. There are default policies that can be invoked if no other rules match. The Default-deny policy for ingress, or Default-deny policy for Egress block all incoming or outgoing traffic respectively. An “allow-all” policy exists for both ingress and egress. This allows all traffic in that direction. Please note the difference in wording between this and the “default-deny” keyword. For the default policies, a policyType: Ingress or policyType: Egress is required depending on the direction of the traffic.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.