In Kubernetes, Network Policies act as a software-defined firewall governing how groups of Pods communicate with each other and other network endpoints. For the CKA exam, understanding this concept is vital for securing cluster networking.
By default, Kubernetes follows an "allow-all" philosophy: …In Kubernetes, Network Policies act as a software-defined firewall governing how groups of Pods communicate with each other and other network endpoints. For the CKA exam, understanding this concept is vital for securing cluster networking.
By default, Kubernetes follows an "allow-all" philosophy: any Pod can talk to any other Pod across namespaces. Network Policies allow you to enforce granular traffic control to override this behavior. However, the enforcement relies entirely on the CNI (Container Network Interface) plugin; simple plugins like Flannel do not support them, while plugins like Calico, Weave Net, and Cilium do. If the CNI does not support policies, creating the resource will have no effect.
To define a policy, you create a `NetworkPolicy` resource using YAML. The core logic relies on the `podSelector`. If a Pod matches the selector, it becomes "isolated," meaning it will reject all traffic unless explicitly allowed by the policy's rules. If a Pod is not selected by any policy, it remains open to all traffic.
A policy specification typically includes:
1. podSelector: Defines the target Pods to secure.
2. policyTypes: Specifies whether the policy controls `Ingress` (incoming traffic), `Egress` (outgoing traffic), or both.
3. Rules: The ingress and egress sections define whitelist rules based on `IPBlock` (CIDR ranges), `namespaceSelector` (traffic from specific namespaces), `podSelector` (traffic from specific Pods via labels), and specific TCP/UDP ports.
A common CKA task involves implementing a "Default Deny" policy. By selecting all Pods in a namespace but providing no allow rules, you effectively block all traffic. You then layer specific policies on top to whitelist necessary communication (e.g., allowing a frontend Pod to access a backend database on port 5432). Mastery involves correctly combining label selectors to achieve the principle of least privilege.
Mastering Network Policies for CKA: /concept/cka/services-networking/network-policies/
What is a Network Policy? A Network Policy is a Kubernetes resource that controls the flow of traffic between Pods, Namespaces, and IP blocks. By default, pods in Kubernetes are non-isolated; they accept traffic from any source. A Network Policy acts essentially as a firewall rule set for Kubernetes Pods, allowing you to whitelist specific traffic.
Why is it important? Network Policies are critical for cluster security. They allow you to implement the principle of least privilege at the network layer. Without them, a compromised pod in one namespace could potentially access sensitive database pods in another. In the CKA exam and real-world scenarios, they are the primary mechanism for enforcing network segmentation and multi-tenancy isolation.
How it works Network Policies are defined using the `networking.k8s.io/v1` API. However, they are enforced by the Network Plugin (CNI), not Kubernetes itself. If your cluster uses a CNI that doesn't support policies (like Flannel), creating the resource will have no effect. Common CNIs that support this include Calico, Weave Net, and Cilium.
The logic follows an additive whitelist model: 1. If no policy selects a pod, it allows all traffic. 2. Once a policy selects a pod (via `podSelector`), the pod is isolated, and only traffic explicitly allowed by the rules is accepted.
How to answer: Define and enforce Network Policies To answer these questions effectively in the exam: 1. Identify the Victim (Target): Find the pod(s) that need protection and note their labels. 2. Determine the Direction: Is the requirement to restrict incoming traffic (Ingress) or outgoing traffic (Egress)? 3. Identify the Allowed Source/Destination: Are we allowing traffic from a specific Namespace, specific Pods, or an IP Block (CIDR)? 4. Draft the YAML: Structure your YAML with `podSelector` (to target the victim), `policyTypes` (Ingress/Egress), and the specific rules.
Exam Tips: Answering Questions on Define and enforce Network Policies • Default Deny Pattern: A common exam task is to "deny all traffic" in a namespace. To do this, create a policy with an empty `podSelector: {}` (selecting all pods) and list `Ingress` in `policyTypes` without providing any rules. This creates a lockdown state. • Namespace vs. Pod Selector: Pay close attention to whether you are allowing traffic from a Pod or a Namespace. Use `namespaceSelector` to allow traffic from all pods in a labeled namespace. Use `podSelector` to allow traffic from specific pods in the same namespace. • Labeling Namespaces: Sometimes the exam asks you to allow traffic from a namespace that doesn't have a label yet. You must run `kubectl label namespace key=value` first, then reference that label in your policy. • The "OR" vs "AND" Trap: Inside a rule, if you list multiple selectors (e.g., `namespaceSelector` and `podSelector`) in a single list item (with a dash `-`), they act as an AND (traffic must match both). If you use separate list items (separate dashes), they act as an OR. • Verification: Always run `kubectl describe networkpolicy ` after applying. The output describes the rules in plain English, which makes it easy to catch logic errors.