Kubernetes NetworkPolicy versus CiliumNetworkPolicy: CCA practice questions

Cilium enforces the standard Kubernetes NetworkPolicy and adds its own resources next to it, and it can run all of them at once. Knowing where the standard API stops tells you when a Cilium resource is needed.

NetworkPolicy works at layers 3 and 4. A policy selects pods in its own namespace with a podSelector, declares policyTypes, and lists allowed peers as podSelector, namespaceSelector or ipBlock together with ports and endPort. Policies are additive allow-lists: a pod is isolated for a direction once any policy with that type selects it. The Kubernetes documentation lists what the API cannot express, and the list maps closely onto Cilium features. There is no explicit deny, no TLS or other application-layer logic, no node-specific policy, no default policy across all namespaces, no targeting of Services by name, and no logging of allowed or blocked connections.

CiliumNetworkPolicy keeps the same namespaced shape but covers layers 3 to 7. It adds HTTP and DNS rules under toPorts, DNS-name destinations with toFQDNs, entities such as world and kube-apiserver, toServices, ICMP type matching, and deny sections. Deny rules take precedence over every allow, including allows written as Kubernetes NetworkPolicy. CiliumClusterwideNetworkPolicy uses the same rule format without a namespace, which gives baselines for all namespaces, and with a nodeSelector it becomes a host policy for the nodes themselves once the host firewall is enabled. Observability of allowed and dropped flows comes from Hubble rather than from the policy API.

Some behaviour differs in detail. With Cilium, ipBlock and CIDR rules do not match in-cluster pod or node addresses by default, because those peers are identified by identity; the option policyCIDRMatchMode set to pods or nodes changes this at the cost of extra identities. Cilium 1.20 also supports the Kubernetes ClusterNetworkPolicy API behind k8sClusterNetworkPolicy.enabled. Its tiers are evaluated in order: Admin, then the NetworkPolicy tier that contains NetworkPolicy, CiliumNetworkPolicy and CiliumClusterwideNetworkPolicy, then Baseline. An Admin-tier rule cannot be overridden by anything below it.

Mixing types is supported but needs care. The Cilium docs warn that the combined set of allowed traffic across several policy types can be hard to reason about and may lead to unintended allows, so many teams pick one primary format and use the others deliberately.