Description
A NetworkPolicy whose pod_selector does not match the intended pod labels may fail to apply the expected network controls. It selects pods in its own namespace; an empty selector selects all pods in that namespace.
A policy prepared for future pods can legitimately select no pods temporarily. Assess actual enforcement using network-plugin support and all policies that apply to the selected pods.
Potential impact
- Intended pods may remain less isolated than expected.
- Selecting the wrong pods can interrupt required communication.
Remediation
- Match the policy namespace and pod_selector to actual pod labels. Check all match_labels or match_expressions conditions.
- Configure policy_types, ingress and egress rules with a supporting network plugin. Test that required traffic succeeds and unwanted traffic fails. Allow rules from multiple policies can be combined.
Examples
These excerpts compare selectors only; the pod spec, policy types and traffic rules are omitted. Check whether app=ngnix pods actually exist before changing the selector. The after example shows matching labels in the default namespace.
Before
hcl
resource "kubernetes_network_policy" "example" {
metadata {
name = "terraform-example-network-policy"
namespace = "default"
}
spec {
pod_selector {
match_labels = {
app = "ngnix"
}
}
}
}
After
hcl
resource "kubernetes_pod" "example" {
metadata {
name = "terraform-example"
labels = {
app = "ngnix2"
}
}
}
resource "kubernetes_network_policy" "example" {
metadata {
name = "terraform-example-network-policy"
namespace = "default"
}
spec {
pod_selector {
match_labels = {
app = "ngnix2"
}
}
}
}
Explanation:
- Before: The policy selects app=ngnix pods. If none exist, it currently has no target pods.
- After: Pod labels and the selector match on app=ngnix2. Matching alone does not configure the intended traffic rules.