Description
Creating NetworkPolicy resources does not enforce traffic restrictions without a network component that implements them. Isolation between sensitive workloads or tenants needs both policies and working enforcement.
Flannel primarily provides connectivity and can be paired with a policy controller or another component such as Calico for enforcement. Check the installed configuration and behavior rather than relying on the plugin name alone.
Potential impact
Without enforcement, internal services may be reachable more broadly than intended, making lateral movement from a compromised workload harder to contain. Separate namespaces alone do not block network traffic.
Remediation
- Confirm that the deployed network plugin and policy controller support and enable the NetworkPolicy features you need.
- Configure enforcement through a supported installation procedure and allow only required ingress and egress, including essential traffic such as DNS.
- Plan connectivity impact and recovery before changes. Test from actual Pods that allowed traffic succeeds and unapproved traffic is blocked.
Examples
These ConfigMaps contain conceptual plugin-selection excerpts, not complete CNI configuration or migration procedures. Changing the ConfigMap name, labels or type alone does not migrate the network.
Before
kind: ConfigMap
apiVersion: v1
metadata:
name: kube-flannel-cfg
namespace: kube-system
labels:
app: flannel
data:
cni-conf.json: |
{
"name": "cbr0",
"plugins": [
{
"type": "flannel"
}
]
}
This shows Flannel connectivity configuration. Check for a separate policy-enforcement component; the excerpt alone does not establish actual isolation.
After
kind: ConfigMap
apiVersion: v1
metadata:
name: kube-flannel-cfg
namespace: kube-system
labels:
app: calico
data:
cni-conf.json: |
{
"name": "cbr0",
"plugins": [
{
"type": "calico"
}
]
}
This conceptually selects Calico. Use its supported installation and required configuration, apply NetworkPolicies and verify actual traffic enforcement.