If you do not understand Network Policies, your Kubernetes cluster becomes a building where every door is unlocked and every stranger can walk into every room. This chapter teaches you how to lock those doors so that only the right pods can talk to the right pods, which is a critical skill for the Certified Kubernetes Administrator exam because 20% of the exam covers Services and Networking, and Network Policies are the single most tested sub-topic within that domain.
Jump to a section
A simple way to picture Network Policies and Secure Connectivity
Your apartment building has 8 floors, 4 flats per floor, and a shared lobby on the ground floor. Without any rules, any resident can walk into any other flat at any time. That would be chaos. Now, you install a security guard at the entrance of each flat door. The guard has a clipboard with a set of rules written by the building management. For example, Flat 3A on the third floor can only receive packages from the postman, not from Flat 2B. Flat 7C can talk to Flat 7D but only if the conversation is about collecting a borrowed ladder. The guard checks every single person who wants to enter or leave a flat. If a delivery driver from Pizza Palace tries to enter Flat 5B but the rulebook says only the postal service can deliver to that flat, the guard blocks the door. The guard does not care about the identity of the person or the content of the package. The guard only cares about the rules on the clipboard: which flat is allowed to receive which type of traffic (like letters, packages, or personal visits) from which other flat or from the outside world (the lobby). This is exactly how a Kubernetes Network Policy works. The guard’s clipboard is the Network Policy YAML file. The flats are pods. The lobby is the internet or another namespace. The guard is the network plugin (like Calico or Cilium) that enforces the rules. The specific rule that Flat 3A can only receive from the postman is a simple ingress rule: only allow traffic from a pod labelled ‘role: postman’ on port 80. Without the guard, any pod can talk to any other pod. With the guard, only permitted traffic flows. The building management updates the clipboard once a week. In Kubernetes, you update the Network Policy YAML and apply it with kubectl.
The building has a fire escape — that is the default rule. If a fire starts, the building management overrides all flat-specific rules and allows everyone to exit through the main stairwell. In Kubernetes, if you create a NetworkPolicy that allows all traffic from a specific namespace for a health check, that rule must be explicitly written. The guard never guesses. The guard never makes exceptions unless the rulebook says so. This is why Network Policies are called ‘allow-list’ systems: everything is blocked by default unless a rule explicitly permits it.
A Kubernetes cluster is a group of machines (servers) that run your applications. Each application runs inside a ‘pod’ — think of a pod as a tiny private room with one program inside. By default, any pod can talk to any other pod, even if they are running different applications on different machines. This is like having a building where every apartment door is always open. That is convenient for communication, but terrible for security.
A ‘Network Policy’ is a set of rules that decides which pods can talk to which other pods and on which ‘ports’ (a port is like a door number — port 80 is for web traffic, port 443 is for secure web traffic, port 3306 is for MySQL databases). If you create a Network Policy that says ‘Pod A can talk to Pod B only on port 80’, then any traffic from Pod A to Pod B on any other port is blocked. Any traffic from Pod A to any pod that is not Pod B is also blocked.
Network Policies use ‘labels’ to identify pods. A label is a key-value pair attached to a pod, like ‘tier: frontend’ or ‘app: payments’. Instead of writing a rule that says ‘Pod A can talk to Pod B by its exact name’, you write a rule that says ‘Any pod with label app: frontend can talk to any pod with label app: backend on port 80’. This is powerful because pods can be created or destroyed at any moment — labels stay attached, and the Network Policy applies to all matching pods automatically.
There are two types of traffic direction in a Network Policy: ‘ingress’ and ‘egress’. Ingress is traffic coming into a pod. Egress is traffic leaving a pod. If you write a policy that only specifies ingress rules, egress traffic is still allowed by default. If you write a policy that only specifies egress rules, ingress traffic is still allowed by default. But the moment you write a policy that has any ingress or egress rules, the default behaviour for that direction changes to ‘deny all’ unless a rule explicitly allows it. This is confusing for many beginners: the default ‘allow all’ is overridden as soon as you write one rule.
Network Policies are enforced by a ‘Container Network Interface (CNI) plugin’ that runs in your cluster. The most common CNI plugins are Calico, Cilium, and Weave Net. Without a CNI plugin that supports Network Policies, your Network Policy YAML file is ignored. The YAML file just sits on the server doing nothing. That is a common trap in the CKA exam: the question might ask you to create a Network Policy, but the cluster might be using a CNI that does not support policies, or the CNI might not be configured to enforce them.
A Network Policy is written in a file called a ‘YAML manifest’. It has four main sections:
‘podSelector’: which pods the policy applies to. If you leave this empty, it applies to all pods in the namespace.
‘policyTypes’: you list either ‘Ingress’, ‘Egress’, or both. This tells Kubernetes which direction this policy controls.
‘ingress’: the list of rules for incoming traffic. Each rule can have ‘from’ (which sources are allowed) and ‘ports’ (which ports are allowed).
‘egress’: the list of rules for outgoing traffic. Each rule can have ‘to’ (which destinations are allowed) and ‘ports’.
Network Policies are ‘namespace-scoped’. That means a Network Policy in the ‘production’ namespace only affects pods in the ‘production’ namespace. It cannot control traffic to or from pods in the ‘staging’ namespace unless you explicitly allow it using a ‘namespaceSelector’.
One more important concept: ‘default deny’. If you create a Network Policy that selects all pods in a namespace but has no ingress rules, you effectively block all incoming traffic to every pod in that namespace. This is a common pattern to lock down a whole namespace. Then you add specific policies to allow only the traffic you need.
Why does this exist? Before Network Policies, administrators had to use firewall rules on individual servers or use complex network segmentation. Network Policies give you a way to define security rules right inside your Kubernetes cluster, using the same tools (kubectl) you use to manage everything else. It replaces the old way of manually configuring iptables rules on each node.
For the CKA exam, you must be able to write a Network Policy YAML from scratch, given a scenario. For example: ‘Create a Network Policy named deny-all that denies all ingress traffic to pods in the default namespace.’ Or: ‘Create a Network Policy that allows traffic from pods with label tier: frontend to pods with label tier: backend on port 3306.’ You will also need to identify what happens when two policies overlap — the most permissive rule wins because rules are ORed together.
Identify the pods and their labels
Before writing a Network Policy, you must know which pods need to communicate. Use 'kubectl get pods --show-labels' to see current pods and their labels. For the CKA exam, the scenario will tell you the labels. In real work, you would ask the development team or read the deployment YAML files.
Create the Network Policy YAML file
Use a text editor (like vi or nano) to create a file, e.g., 'policy.yaml'. Start with the standard Kubernetes manifest structure: apiVersion: networking.k8s.io/v1, kind: NetworkPolicy, metadata: name: my-policy, spec:. The spec contains podSelector, policyTypes, ingress, and egress sections.
Define the podSelector
Under 'spec.podSelector', add 'matchLabels' with the label that identifies the target pods. For example, 'matchLabels: tier: database' selects all pods with that label. If you want to select all pods, use empty brackets: 'podSelector: {}'.
Set the policyTypes
Under 'spec.policyTypes', list the directions you want to control. For example: 'policyTypes: [Ingress, Egress]' to control both incoming and outgoing traffic. If only ingress is specified, egress remains unrestricted. If only egress is specified, ingress remains unrestricted.
Write the ingress rules
Under 'spec.ingress', add a list of rules. Each rule has a 'from' section (which sources are allowed) and a 'ports' section. For example: 'from: - podSelector: matchLabels: tier: frontend' and 'ports: - port: 3306'. This allows traffic only from pods with label 'tier: frontend' on port 3306. If you want to allow traffic from a namespace, use 'namespaceSelector'.
Write the egress rules
Under 'spec.egress', add rules similar to ingress but with 'to' instead of 'from'. For example: 'to: - ipBlock: cidr: 10.0.0.0/8' and 'ports: - port: 443'. This allows outgoing traffic only to IPs in the 10.0.0.0/8 range on port 443. Remember to also allow DNS traffic if needed.
Apply and verify the policy
Run 'kubectl apply -f policy.yaml -n <namespace>' to create the policy. Then use 'kubectl describe networkpolicy <name>' to see the summary. Test connectivity with 'kubectl exec' and tools like 'curl' or 'nc' to confirm the policy works as expected.
An IT professional working at a financial services company called ‘PayRight Inc.’ is responsible for securing their Kubernetes cluster that runs a payment processing system. The system has three components: a frontend web server (handles customer requests), a backend API server (processes payments), and a database server (stores transaction data). The database contains sensitive credit card information. The company’s security policy states that only the backend API server should be able to talk to the database, and only on port 3306. The frontend should never talk directly to the database. Also, the backend should only talk to the database and to the frontend. No pod should be able to reach the internet except the frontend, which needs to call an external fraud-checking service.
Step one: The IT professional creates a namespace called ‘payright-prod’ and deploys the three components with appropriate labels. The frontend pod has label ‘tier: frontend’, the backend pod has label ‘tier: backend’, and the database pod has label ‘tier: database’.
Step two: To enforce the security policy, the IT professional writes a Network Policy YAML file. First, they create a ‘default deny’ policy for all pods in the namespace. This ensures that if any new pod is created without explicit permissions, it cannot talk to anything. The policy looks like this: it selects all pods (empty podSelector), and specifies both ‘Ingress’ and ‘Egress’ in policyTypes, but leaves the rules empty. This blocks all traffic in and out.
Step three: The IT professional writes a specific Network Policy for the database pod. The podSelector selects ‘tier: database’. The ingress rule says: allow traffic from pods with label ‘tier: backend’ on port 3306. The egress rule says: allow no traffic (because the database should not initiate connections to anything).
Step four: The IT professional writes a policy for the backend pod. Ingress allows traffic from ‘tier: frontend’ on port 8080 (the API endpoint). Egress allows traffic to ‘tier: database’ on port 3306. Note: the backend also needs to talk to the database, but the database policy already allows ingress from backend, so this egress rule on the backend is just a safety measure — it restricts the backend from contacting any other pod except the database.
Step five: The IT professional writes a policy for the frontend pod. Ingress allows traffic from anywhere (the internet) on ports 80 and 443 because customers connect to the frontend via a web browser. Egress allows traffic to ‘tier: backend’ on port 8080, and also allows traffic to any external IP on port 443 (for the fraud-checking API).
Step six: The IT professional applies all policies using ‘kubectl apply -f policy.yaml’. They then test by deploying a temporary pod with a ‘netcat’ tool and trying to connect to the database from the frontend namespace. The connection is blocked. They verify the backend can connect to the database. The security audit passes.
Common real-world tools used alongside Network Policies include: - ‘kubectl describe networkpolicy <name>’ to see the rules. - ‘kubectl get networkpolicy’ to list all policies. - ‘kubectl exec’ to run a command inside a pod to test connectivity (e.g., ‘kubectl exec frontend-pod -- curl backend-service:8080’). - ‘tcpdump’ or ‘wireshark’ for advanced debugging if policies are blocking unintended traffic.
The professional must also regularly review policies because new applications are added to the cluster. They use a tool like ‘Polaris’ or ‘Kube-bench’ to audit policies against best practices. They also set up alerts in their monitoring system (Prometheus) to detect when traffic is being dropped by a Network Policy, which indicates either a misconfiguration or an attempted attack.
The CKA exam tests Network Policies in a very specific way. You will be given a YAML editor terminal (often inside a web-based IDE) and asked to either create a Network Policy from scratch, debug an existing one, or identify what a given policy will do. The exam environment runs a real Kubernetes cluster with a CNI plugin that supports Network Policies (usually Calico). If you do not enable the CNI plugin, the policies will be created but will have no effect — a common trap.
Here are the exact concepts the exam loves to test:
‘Default deny all traffic’: They will ask you to create a Network Policy that denies all ingress traffic to all pods in a namespace. The trick is to set ‘podSelector: {}’ (empty brackets) and ‘policyTypes: [Ingress]’ with no ingress rules. Many candidates forget the empty podSelector or add an ingress rule by mistake.
‘Allow specific traffic from a pod with a label’: They will give a scenario like ‘allow traffic from pods with label app: web to pods with label app: api on port 8080’. You must use a ‘matchLabels’ block inside ‘from’.
‘Allow traffic from a specific namespace’: You might need to allow traffic from pods in namespace ‘monitoring’ to your pod. Use ‘namespaceSelector: matchLabels: name: monitoring’. The label ‘name’ is the actual name of the namespace — this is pre-set by Kubernetes.
‘Combining podSelector and namespaceSelector’: You can use both in the same rule. For example, allow traffic from pods with label ‘app: grafana’ only if those pods are in namespace ‘monitoring’. This is done by adding both ‘podSelector’ and ‘namespaceSelector’ under a single ‘from’ entry. If you put them in separate ‘from’ entries, they become OR logic (allow from either), not AND logic (allow from both).
‘Ports in the rule’: You must specify port numbers, not service names. For example, port 3306 for MySQL, not ‘mysql’. The exam will give you the port number.
‘Egress rules’: They will ask you to restrict egress traffic to a specific IP block (CIDR). For CIDR matching, you use ‘ipBlock’. Example: allow egress to ‘0.0.0.0/0’ but deny to ‘10.0.0.0/8’. Or allow egress to two specific IP addresses using two ‘to’ entries. The trap here is that IP blocks in egress rules also affect DNS traffic — if you restrict egress to only two IPs, the pod cannot resolve DNS names to those IPs unless you also allow DNS (port 53) to the cluster DNS service.
‘Policy ordering’: The exam does not test that policies are applied in any specific order. All policies are evaluated together. If one policy allows traffic and another denies it, the traffic is allowed because rules are ORed. The only way to deny is to not have an allow rule.
‘Creating vs. applying’: The exam will ask you to ‘create’ a Network Policy. You must write a YAML file and then run ‘kubectl apply -f <filename>’. They do not accept ‘kubectl run’ or ‘kubectl expose’ for Network Policies.
trap patterns to watch out for: - ‘Empty policyTypes’: If you do not specify policyTypes, the default is only ‘Ingress’. If the scenario requires both ingress and egress, you must explicitly list both. - ‘Using service names in ports’: The YAML port field expects a numerical port or a named port from the pod spec. Using a service name like ‘http’ will not work. - ‘Forgetting to scope to a namespace’: Network Policies are namespace-scoped by default. If you do not specify a namespace, the policy applies to the namespace you are currently working in. The exam might ask you to create a policy in namespace ‘xyz’, so you need to use ‘kubectl apply -f file.yaml -n xyz’ or add ‘namespace: xyz’ in the YAML. - ‘CIDR with egress and no DNS exception’: If you restrict egress to a specific list of IPs, the pod cannot reach the internal DNS server unless you also allow egress to the cluster IP of the DNS service on port 53. This is a very common exam scenario.
Key definitions to memorise: - ‘podSelector: {}’ selects all pods in the namespace. - ‘policyTypes: [Ingress, Egress]’ is needed if you want both directions controlled. - ‘from’ and ‘to’ are lists of ‘peers’ — each peer can be a podSelector, namespaceSelector, or ipBlock. - ‘ports’ is a list of port numbers with an optional ‘protocol’ field (default TCP).
Network Policies are allow-list rules: everything not explicitly permitted is denied, but only after a policy selects the pod.
A Network Policy must have a CNI plugin (like Calico or Cilium) installed and configured in the cluster to be enforced.
You control traffic direction with 'policyTypes: [Ingress, Egress]' — omitting a direction means it is not restricted by that policy.
Use 'podSelector: {}' to select all pods in a namespace for a default deny policy.
Combine 'podSelector' and 'namespaceSelector' inside a single 'from' entry to require both conditions (AND logic).
When restricting egress to specific IP addresses with 'ipBlock', you must also allow egress to the cluster DNS service on port 53 or the pod cannot resolve domain names.
These come up on the exam all the time. Here's how to tell them apart.
Network Policy (Ingress Rule)
Controls incoming traffic to a pod
Uses 'from' to specify allowed sources
If specified, default changes to 'deny all ingress' unless rules allow
Network Policy (Egress Rule)
Controls outgoing traffic from a pod
Uses 'to' to specify allowed destinations
If specified, default changes to 'deny all egress' unless rules allow
podSelector in 'from'
Selects specific pods by their labels within any namespace
Example: matchLabels: app: web
Only pods with matching labels are allowed as sources
namespaceSelector in 'from'
Selects all pods within a specific namespace
Example: matchLabels: name: monitoring
All pods in that namespace are allowed as sources, regardless of their labels
Default pod communication without policy
All traffic allowed in and out
No restrictions unless a rule is written
Pod is completely open
Default pod communication with a policy
Traffic restricted to what the policy allows
Default changes to 'deny all' for specified directions
Pod is locked down unless an allow rule matches
Network Policy (allow-list)
Controls network traffic between pods
Operates at the network layer (ports, IPs)
Enforced by CNI plugin
Kubernetes RBAC (role-based access control)
Controls who can perform API operations (e.g., kubectl commands)
Operates at the API layer (create, delete pods)
Enforced by the Kubernetes API server
Mistake
Network Policies block traffic to and from pods automatically as soon as you create the policy.
Correct
A Network Policy only blocks traffic that does not match an allow rule. If you create a policy with an ingress rule that allows traffic on port 80, all traffic on port 80 is allowed, but traffic on other ports is blocked. No rule means no change to the default 'allow all'.
Beginners think a policy is like a firewall rule that says 'deny X'. In Kubernetes, policies are allow-lists: everything not explicitly allowed is denied. This is the opposite of how most people think about security.
Mistake
A Network Policy created in one namespace can protect pods in another namespace.
Correct
A Network Policy only applies to pods within the same namespace where it is created. To affect pods in another namespace, you must create a policy in that namespace, or use a 'namespaceSelector' in the 'from' or 'to' rule of a policy in your own namespace to allow traffic from pods in another namespace.
People confuse namespace boundaries with network boundaries. Namespaces are logical groupings, not network segments. Each namespace has its own set of policies.
Mistake
If a pod has no Network Policy applied to it, no traffic is allowed to or from that pod.
Correct
If no Network Policy selects a pod, the default Kubernetes behaviour allows all traffic to and from that pod. The pod is completely open. Only when a policy selects the pod does the default change to 'deny all' for the directions specified in the policy's 'policyTypes'.
This misunderstanding comes from thinking policies are universal defaults. In reality, a policy is an opt-in restriction. If you want to lock down a pod, you must explicitly write a policy that selects it.
Mistake
You cannot allow traffic from a specific IP address to a pod using a Network Policy.
Correct
You can allow traffic from a specific IP address or CIDR block using the 'ipBlock' field under 'from' in an ingress rule. For example: 'from: - ipBlock: cidr: 192.168.1.0/24' allows traffic from that subnet.
Many beginners think Network Policies only work with pod labels. The 'ipBlock' feature is less well-known but is tested in the CKA exam, especially for egress rules to external services.
Mistake
Applying a Network Policy immediately drops all existing connections that do not match the new rules.
Correct
Kubernetes Network Policies are connection-based, not packet-based. Existing established connections are not terminated when a policy is created or updated. Only new connections are checked against the policy. This means if a connection was established before the policy was applied, it will continue until it ends naturally.
People expect immediate enforcement like a firewall rule change. But Kubernetes uses conntrack (connection tracking) and does not retroactively kill established connections. The exam does not test this nuance directly, but understanding it prevents confusion in practice.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The Network Policy YAML is accepted and stored in etcd, but it has no effect. Pods can still communicate freely. You must install a CNI plugin like Calico that enforces policies. The CKA exam uses a cluster with Calico pre-installed.
Yes. Network Policies apply regardless of whether pods are on the same node or different nodes. The CNI plugin enforces the rules at the network layer, so same-node traffic is also restricted.
In the ingress rule, use 'namespaceSelector: matchLabels: name: <namespace-name>'. The namespace must have the label 'name' set to its own name by default. For example: 'from: - namespaceSelector: matchLabels: name: monitoring'.
No. Network Policies are allow-list only. You cannot write a rule that says 'deny traffic from Pod X'. Instead, you create a policy that allows traffic from all pods except Pod X. If you want to isolate Pod X, you do not include it in any allow rule.
The main 'podSelector' (at the top of spec) selects which pods the policy applies to. The 'podSelector' inside the 'from' or 'to' section selects which source or destination pods are allowed. They serve different purposes.
A Network Policy controls traffic to pods, not to service IPs. When traffic hits a service, it is forwarded to a pod behind that service. The Network Policy then evaluates the traffic based on the pod's labels. So the policy still affects the connection.
You've finished Network Policies and Secure Connectivity. Continue through the CKA study guide to build a complete picture of the exam.
Done with this chapter?