CKS — Network Policies Advanced

2 minute read

Chapter Overview

The CKS exam expects NetworkPolicy mastery far beyond CKA level. While CKA tests whether you can write a basic NetworkPolicy, CKS tests whether you can design and implement a zero-trust network architecture inside a Kubernetes cluster.

This chapter covers advanced NetworkPolicy patterns that are critical for the CKS exam:

  • Default deny policies — the foundation of zero-trust networking
  • Namespace isolation — preventing cross-namespace traffic in multi-tenant clusters
  • Egress control — restricting outbound traffic from pods
  • CIDR & IP block policies — blocking cloud metadata endpoints, controlling traffic by IP range
  • Testing & debugging — verifying policies work and troubleshooting when they don’t

Why This Matters for CKS

NetworkPolicy questions appear across multiple CKS domains:

CKS Domain NetworkPolicy Relevance
Cluster Setup (10%) Default deny, namespace isolation
System Hardening (15%) Egress restrictions, metadata blocking
Minimize Microservice Vulnerabilities (20%) Pod-to-pod isolation, least-privilege networking

A single NetworkPolicy question on the CKS exam can easily be worth 4–7% of your total score. Getting it wrong is not an option.

Prerequisites

This chapter assumes you already understand:

  • NetworkPolicy podSelector, namespaceSelector, and ipBlock syntax
  • policyTypes field (Ingress, Egress)
  • How labels and selectors work
  • Basic kubectl operations

If any of the above is unfamiliar, review the CKA NetworkPolicy material first.

Topics

# Topic Link
1 Default Deny Policies Default Deny Policies
2 Namespace Isolation Namespace Isolation
3 Egress Policies Egress Policies
4 CIDR & IP Block Policies CIDR & IP Block Policies
5 Network Policy Testing Network Policy Testing
6 Hands-On Lab Hands-On Lab

Key Patterns You Must Know

1. Default Deny + Allow DNS

The most common CKS pattern. Every secure namespace starts with:

  1. Default deny all ingress and egress
  2. Allow DNS egress (port 53) so pods can resolve service names
  3. Allow only the specific traffic each workload needs

2. Namespace Isolation

In multi-tenant clusters, namespaces must be isolated from each other. Pods in team-a should not be able to reach pods in team-b unless explicitly allowed.

3. Cloud Metadata Blocking

Block egress to 169.254.169.254/32 from all pods. This prevents pods from accessing cloud provider metadata APIs, which can expose IAM credentials and other sensitive data.

4. Egress Lockdown

Restrict which external IPs and internal services each pod can reach. A compromised pod with unrestricted egress can exfiltrate data to any destination.

CNI Plugin Requirement

NetworkPolicies require a CNI plugin that supports them.

  • Calico — full support (ingress + egress)
  • Cilium — full support (ingress + egress + L7)
  • Weave Net — ingress support
  • Flannel — NO support (policies are silently ignored)

On the CKS exam, the cluster uses a CNI that supports NetworkPolicies. In your practice environment, use Calico or Cilium.

Quick Reference

# List all NetworkPolicies in a namespace
kubectl get networkpolicy -n <namespace>

# Describe a specific NetworkPolicy
kubectl describe networkpolicy <name> -n <namespace>

# Check pod labels (for debugging selectors)
kubectl get pods -n <namespace> --show-labels

# Check namespace labels
kubectl get namespaces --show-labels

# Test connectivity from a temporary pod
kubectl run test --rm -it --image=busybox -n <namespace> -- /bin/sh

Work through each topic in order. The hands-on lab at the end ties everything together.

Updated:

You may also enjoy