Skip to content

Security

Related Notes

index | architecture | operations | architecture

Overview

Flannel has a deliberately minimal security model. It provides inter-node pod connectivity but does not include any network policy enforcement, identity-based access control, or built-in observability. For clusters requiring network segmentation, encryption, or compliance-grade security, Flannel must be supplemented with additional tools or replaced entirely.

What Flannel Does NOT Provide

No built-in security features

Flannel is a pure overlay network fabric. It does not implement:

  • Kubernetes NetworkPolicy -- no support whatsoever. NetworkPolicy resources are silently ignored.
  • Custom network policies -- no Calico-style or Cilium-style policy CRDs.
  • Identity-based enforcement -- all pods on the overlay can reach all other pods by default.
  • L7 filtering -- no HTTP, gRPC, or DNS inspection.
  • Flow logging or observability -- no Hubble-equivalent, no packet capture, no flow logs.
  • Runtime security -- no Tetragon-equivalent for process or file monitoring.
  • Service mesh integration -- no sidecar or ambient mesh support.

This means that in a default Flannel deployment, every pod can communicate with every other pod across all namespaces without restriction.

Encryption Options

VXLAN Backend (Default) -- No Encryption

The default VXLAN backend does not encrypt inter-node traffic. VXLAN packets are plain UDP encapsulation on the wire:

  • Risk -- any entity with access to the physical network can sniff pod-to-pod traffic between nodes.
  • Mitigation -- rely on underlying network encryption (IPsec tunnels, cloud provider VPC encryption, or physical network encryption).

WireGuard Backend -- Encrypted

Flannel includes a WireGuard backend that encrypts all inter-node pod traffic:

{
  "Network": "10.244.0.0/16",
  "Backend": {
    "Type": "wireguard",
    "ListenPort": 51820,
    "PersistentKeepaliveInterval": 25
  }
}
  • Encryption -- uses ChaCha20-Poly1305 (WireGuard default). All pod traffic between nodes is encrypted transparently.
  • NAT traversal -- PersistentKeepaliveInterval enables keepalive packets for nodes behind NAT.
  • Pre-shared key (PSK) -- optional PSK for additional post-quantum resistance.
  • Limitations -- only encrypts inter-node traffic. Pod-to-pod traffic on the same node is not encrypted (traverses the cni0 bridge in plaintext). No per-pod or per-namespace encryption granularity.

WireGuard vs Cilium/Calico encryption

Flannel's WireGuard backend provides transport encryption comparable to Calico WireGuard or Cilium WireGuard. However, Flannel still lacks the policy enforcement and identity-based security that Calico and Cilium provide alongside encryption.

host-gw Backend -- No Encryption

The host-gw backend creates plain IP routes with no encapsulation and no encryption. Traffic is sent as raw packets on the physical network. Only suitable for trusted network environments.

etcd Access Control

When using etcd as the subnet manager backend, the security of the etcd cluster directly affects Flannel:

  • etcd TLS -- Flannel supports mutual TLS for etcd communication via --etcd-certfile, --etcd-keyfile, and --etcd-cafile flags.
  • RBAC -- etcd v3 supports role-based access control. Create a dedicated Flannel user with read/write access only to the /coreos.com/network/ prefix.
  • Network isolation -- etcd should not be exposed to pod networks. Use separate network interfaces or firewall rules.

When using the Kubernetes API backend (--kube-subnet-mgr), security relies on Kubernetes API server authentication and RBAC. The Flannel DaemonSet uses a ServiceAccount with permissions to read/write ConfigMaps and Node objects.

iptables and IP Masquerade

Flannel can configure iptables rules for egress NAT:

  • --ip-masq=true -- configures MASQUERADE rules for traffic leaving the Flannel network. Pod traffic to external IPs is NAT'd to the node's IP address.
  • --iptables-forward-rules=true (default) -- adds ACCEPT rules to the iptables FORWARD chain to allow traffic forwarding.
  • --iptables-resync=5 -- resync period for iptables rules in seconds.

These are basic connectivity rules, not security policies. They do not provide segmentation or access control.

When to Use Calico or Cilium Instead

Requirement Flannel Recommended Alternative
Kubernetes NetworkPolicy Not supported Calico or Cilium
Microsegmentation Not supported Calico (GlobalNetworkPolicy, tiers) or Cilium (CiliumNetworkPolicy)
L7 policy (HTTP/gRPC) Not supported Cilium
Identity-based policy Not supported Cilium
Encryption (WireGuard) Supported via backend Calico or Cilium (both support WireGuard with policy)
Flow observability Not available Cilium (Hubble)
Runtime security Not available Cilium (Tetragon)
eBPF acceleration Not available Calico (eBPF mode) or Cilium
Large scale (1000+ nodes) Limited scalability Calico or Cilium
Compliance (PCI, HIPAA) Insufficient alone Calico or Cilium with audit logging

Common Upgrade Paths

  1. Flannel + Calico (Canal) -- Canal combines Flannel's overlay networking with Calico's network policy engine. This is the simplest upgrade path for existing Flannel deployments that need policy enforcement.

  2. Replace with Calico -- full migration from Flannel to Calico provides BGP routing, policy, eBPF dataplane, and WireGuard encryption in a single CNI plugin. Requires re-cabling the cluster network.

  3. Replace with Cilium -- migration from Flannel to Cilium provides eBPF-based networking, identity-based policy, Hubble observability, and kube-proxy replacement. Best for clusters requiring advanced security and observability.

Security Checklist for Flannel Deployments

Item Action
Encryption Use the WireGuard backend for production clusters
etcd TLS Enable mutual TLS for etcd communication
etcd RBAC Create a dedicated Flannel user with minimal permissions
Egress NAT Enable --ip-masq for pods that need internet access
Network isolation Use cloud VPC security groups or physical firewalls for external traffic filtering
Network policy Deploy Calico policy controller alongside Flannel (Canal pattern) if segmentation is needed
Monitoring Use external tools (Prometheus node exporter, packet capture) for traffic visibility
Node hardening Restrict SSH access, use read-only root filesystem, limit privileged containers

Sources