Lie #4 of 4
"Protected", says the namespace.
Four network policies in the list, three of them enforced. The fourth has an In operator inside an ingress rule with no values under it, which the Cilium operator cannot parse, so it throws the rule away and keeps the object. The name is the same, the age is the same, and the selector at the top still reads as if it covers those pods, which are now open. The only record is a condition inside the policy's status, and no ordinary list of custom resources shows it. Rubick puts that answer first in the row and names the pods left uncovered.
Valid: False · invalid label selector: matchExpressions[0].values: Required value: must be specified when `operator` is 'In' or 'NotIn'
kubectl get cnp prints a VALID column, so the CLI is not fooled.
Reproduce it
One cluster, one typo.
This one needs a CNI that actually enforces policy, so the throwaway cluster is a little larger than the others: kind without its default network plugin, then Cilium on top. The typo is an In operator with no values under it, four lines deep in an ingress rule, which is easy to write and hard to spot again afterwards.
kind create cluster --config https://rubick.tech/lies/cilium-kind.yamlhelm repo add cilium https://helm.cilium.io/ && helm install cilium cilium/cilium -n kube-system --set ipam.mode=kuberneteskubectl apply -f https://rubick.tech/lies/protected.yamlkubectl -n rubick-lies get cnp# kubectl prints a VALID column, so the CLI is not fooled. A list of custom resources shows four rows and stops there.