Learn Flannel - Security & Hardening

#Introduction

Every CNI has its own security model. Flannel honestly chooses to focus on connectivity: connecting Pods quickly and reliably. The consequence is that securing the inter-node traffic layer must be done explicitly.

Episode 13 dissects Flannel's security model, then covers hardening from two sides: encrypting inter-node traffic through the WireGuard and IPsec backends, and securing the Flannel DaemonSet itself.

#Flannel's Security Model

#Connectivity, Not Policy

Flannel handles the networking layer with a single goal: making Pods reach each other. It does not enforce NetworkPolicy and it does not offer isolation between workloads. This is not a shortcoming; it is a design decision that keeps Flannel simple.

The consequence is clear: security above Flannel must be built from other components. NetworkPolicy can be added through a policy engine such as Calico policy-only or Cilium, which we will discuss in episode 14. Segmentation and encryption of inter-node traffic are handled through the backend, covered in this episode.

#Flannel's Threat Model

Flannel's threat model covers: inter-node traffic that can be intercepted on the host network, a ConfigMap that unauthorized parties could modify, and a flanneld image that could carry an older version with vulnerabilities. These three points are what need hardening.

#Backend Encryption: WireGuard

#Encrypted Inter-Node Traffic

WireGuard encrypts all traffic between the tunnel interfaces of nodes. If you run on a network you cannot trust, for example a shared provider network, this backend keeps your Pod traffic unreadable to others.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "wireguard",
      "Port": 51820
    }
  }

With Type: wireguard, every node builds a WireGuard tunnel to the other nodes. UDP port 51820 must be opened in the firewall; the details are in episode 15.

#Verifying the Tunnel

To make sure the tunnel is up, check the WireGuard interface on a node:

ip link show

The output of ip link show displays an interface named wg0 or similar. Its presence means the WireGuard backend is active on that node.

#Backend Encryption: IPsec

#The Enterprise Alternative

IPsec is an older standard widely used in enterprise environments that already have IPsec policies. Flannel integrates it through strongSwan, using IKEv2 for key negotiation.

net-conf.json: |
  {
    "Network": "10.244.0.0/16",
    "Backend": {
      "Type": "ipsec"
    }
  }

The IPsec backend requires strongSwan and the corresponding kernel modules to be available on the nodes. The ports used are 500 and 4500 for IKE and NAT traversal.

#WireGuard vs IPsec

WireGuard is simpler, faster, and built on a modern kernel. IPsec is more accepted in environments with standard policies and audits that demand certain certifications. The choice depends on organizational policy, not performance alone.

#Hardening the DaemonSet

#Image Pinning and Updates

Always pin the flanneld image to a specific version and update it regularly. A floating tag like latest can bring unexpected changes when the DaemonSet is restarted. Use the full version tag:

kubectl get ds -n kube-flannel kube-flannel-ds -o jsonpath='{.spec.template.spec.containers[0].image}'

The output of kubectl get ds -n kube-flannel kube-flannel-ds shows the current image. Make sure it is a version tag such as docker.io/flannel/flannel:v0.28.8, not latest.

#Restrict ConfigMap Access

CVE-2026-32241 reminds us that Flannel's configuration can be an attack vector. Restrict who can modify the kube-flannel-cfg ConfigMap through RBAC. Only the platform team should be able to change the backend and the flanneld arguments.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: flannel-admin
  namespace: kube-flannel
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "watch", "update"]

The Role above grants ConfigMap update access only to entities explicitly tasked with managing Flannel.

#A Sensible Security Context

flanneld needs certain privileges because it manages the host network, but do not grant unnecessary rights. Limit mounts, use readOnlyRootFilesystem where possible, and do not run the container as root unless flanneld's operation on the node requires it.

#Conclusion

Episode 13 frames Flannel security honestly: Flannel handles connectivity, and you handle the security of inter-node traffic through encryption backends and DaemonSet hardening.

Key takeaways:

• Flannel focuses on connectivity and does not enforce NetworkPolicy.
• WireGuard encrypts inter-node traffic through a UDP port 51820 tunnel.
• IPsec uses strongSwan with IKE ports 500 and 4500.
• Pin the flanneld image to a full version, not the latest tag.
• Restrict edit access to the kube-flannel-cfg ConfigMap with RBAC.
• CVE-2026-32241 is a reminder of the importance of updates and configuration restrictions.

In the next episode, episode 14, we will complete the security picture: the network policy ecosystem — why Flannel does not enforce NetworkPolicy, and how to add a policy engine such as Calico policy-only or Cilium on top of Flannel without replacing the CNI.