Skip to main content
This guide explains how to restrict which workloads can communicate inside a Kubernetes cluster using both the native Kubernetes NetworkPolicy API and Cilium’s enhanced policy primitives. By default, Kubernetes clusters permit pod-to-pod communication across the cluster. To adopt a least-privilege posture you must explicitly express which traffic is allowed — for example, preventing Pod 2 from talking to Pod 6. Cilium builds on Kubernetes NetworkPolicy with eBPF-powered enforcement, richer selectors, and L7 controls to make those restrictions more powerful and observable.
A slide titled "Security – Introduction" showing a Kubernetes cluster with two nodes (Node 1 and Node 2), each containing four pods (Pod 1–4 and Pod 5–8). A dashed line between the nodes ends at a red “X,” indicating inter-node communication is blocked or denied.
What this page covers:
  • Kubernetes NetworkPolicy — the native API for expressing allowed traffic between pods, namespaces, and IP blocks.
  • Cilium NetworkPolicy (CNP) and Clusterwide CiliumNetworkPolicy (CCNP) — Cilium’s extended, eBPF-based policy types that add identity-based selectors, richer L7 rules, and cluster-scoped enforcement.
Kubernetes NetworkPolicy is opt-in: if no policies select a pod, that pod remains reachable by other pods. When a pod is selected by one or more NetworkPolicy resources, traffic is restricted according to those policies, allowing you to adopt a least-privilege model for the selected pods.
Why use Cilium for network security
  • Kernel-level enforcement with eBPF for high performance and precise policy enforcement (including inter-node traffic).
  • Identity-based policies using labels (and integrating with external identity providers) rather than relying solely on IP addresses, which improves policy stability as pods move.
  • L7 filtering and visibility (HTTP, gRPC, Kafka, DNS, etc.) so you can write policies based on HTTP paths, methods, or Kafka topics, not just ports.
  • Both namespace-scoped (CiliumNetworkPolicy, CNP) and cluster-scoped (CiliumClusterwideNetworkPolicy, CCNP) objects to express either granular or broad policies.
Policy type comparison
Resource TypeScopeUse CaseExample CLI
Kubernetes NetworkPolicyNamespace-scopedAllow/deny traffic based on pod selectors, namespace selectors, and IPBlockskubectl apply -f networkpolicy.yaml
Cilium CiliumNetworkPolicy (CNP)Namespace-scoped with Cilium extensionsIdentity-based policies, L7 rules, richer match semanticskubectl apply -f cnp.yaml
Cilium CiliumClusterwideNetworkPolicy (CCNP)Cluster-scopedApply consistent policies across namespaces or the whole clusterkubectl apply -f ccnp.yaml
Authoring tips
  • Start with a default deny for critical workloads, then add explicit allow rules for required traffic.
  • Use label-based selectors (identities) where possible so policies remain correct as IPs change.
  • Combine L4 (ports/protocols) and L7 filters (HTTP methods, paths) to enforce intent at the application layer.
  • Test policies incrementally in a staging environment and use observability tools (Cilium Hubble, cilium monitor) to validate enforcement.
Next sections (in this guide) show:
  • Example NetworkPolicy YAML and how it behaves in a cluster.
  • Example CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy demonstrating identity-based and L7 rules.
  • How Cilium enforces policies at the eBPF level (including inter-node enforcement as illustrated above).
  • Techniques to implement and verify a least-privilege network posture.
Links and references
Tip: Use kubectl describe and Cilium’s hubble tools to observe which policy matches traffic during testing. This helps iterate policies without risking production outages.

Watch Video