NetworkPolicy fundamentals — the cluster firewall and the CNI dependency

NetworkPolicy is the cluster firewall. The policy is enforced by the CNI plugin: Calico, Cilium, and Weave enforce NetworkPolicy; Flannel does NOT. A cluster running Flannel alone has no NetworkPolicy enforcement — every Pod can reach every other Pod. This lesson walks the NetworkPolicy, the CNI dependency, and the operational discipline.

What NetworkPolicy is

NetworkPolicy is a Kubernetes API object that defines the network traffic rules for a set of Pods:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: prod-app-default-deny
  namespace: prod-app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

The policy selects a set of Pods and defines the ingress and egress rules.

flowchart LR
    A[NetworkPolicy] --> B[Pod selector]
    A --> C[Ingress rules]
    A --> D[Egress rules]
    B --> E[Selected Pods]
    C --> E
    D --> E

The NetworkPolicy is the cluster’s firewall. The policy is enforced at the network layer.

The CNI dependency

The NetworkPolicy is enforced by the CNI plugin. The CNI plugin’s support for NetworkPolicy varies:

A cluster running Flannel alone has no NetworkPolicy enforcement. The NetworkPolicy API is accepted by the cluster, but the rules are not enforced. The Pods can reach each other regardless of the policy.

The default-deny pattern

The production pattern is default-deny with explicit allow:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: prod-app-default-deny
  namespace: prod-app
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

The podSelector: {} matches every Pod in the namespace. The policyTypes declares both Ingress and Egress. The result is that every Pod in the namespace has no ingress and no egress by default.

The cluster operator then adds explicit allow policies:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: prod-app-allow-dns
  namespace: prod-app
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

The default-deny pattern is the basis of zero-trust networking.

The policy types

The NetworkPolicy supports three policy types:

• Ingress: the policy applies to ingress traffic to the selected Pods.
• Egress: the policy applies to egress traffic from the selected Pods.
• Ingress and Egress: both.

A policy with no rule in a type allows all traffic in that type. A policy with a rule allows only the specified traffic.

The failure modes

The NetworkPolicy’s failure modes:

• CNI does not enforce: the cluster runs Flannel alone; the NetworkPolicy is not enforced. The fix is to switch to a CNI that enforces NetworkPolicy.
• Default-deny too strict: the default-deny policy blocks legitimate traffic. The fix is to add explicit allow policies.
• Pod selector mismatch: the policy does not match the intended Pods. The fix is to verify the podSelector.
• Namespace selector mismatch: the policy does not match the intended namespace. The fix is to verify the namespaceSelector.
• Port mismatch: the policy does not match the intended port. The fix is to verify the ports.

The operational discipline

The NetworkPolicy’s operational discipline:

• Audit the CNI’s NetworkPolicy enforcement. The cluster operator must verify the CNI enforces NetworkPolicy.
• Use the default-deny pattern. The default-deny pattern is the basis of zero-trust networking.
• Test the NetworkPolicy in staging. The NetworkPolicy must work for the workload.
• Monitor the NetworkPolicy’s metrics. The CNI exposes NetworkPolicy metrics.
• Document the NetworkPolicy. The NetworkPolicy is the cluster’s firewall.
• Plan the NetworkPolicy’s evolution. The NetworkPolicy can be extended with CNI-specific resources.

Quiz

Production discipline

• The CNI plugin’s NetworkPolicy enforcement is the basis of the cluster’s firewall. The cluster operator must verify the CNI.
• Audit the CNI’s NetworkPolicy enforcement. The cluster operator must verify the CNI enforces NetworkPolicy.
• Use the default-deny pattern. The default-deny pattern is the basis of zero-trust networking.
• Test the NetworkPolicy in staging. The NetworkPolicy must work for the workload.
• Monitor the NetworkPolicy’s metrics. The CNI exposes NetworkPolicy metrics.
• Document the NetworkPolicy. The NetworkPolicy is the cluster’s firewall.
• Plan the NetworkPolicy’s evolution. The NetworkPolicy can be extended with CNI-specific resources.
• Train the security team on the NetworkPolicy. The NetworkPolicy is the basis of the cluster’s security.
• Audit the NetworkPolicy at every change. The NetworkPolicy is critical configuration.