Open bogatuadrian opened 1 month ago
bogatuadrian@ We will update our documentation to state this more explicitly. In strict mode when no network policies are applied the default is deny all. Once any kind of network policy is applied (ingress or egress), the default deny is no longer applicable. From here it is as upstream states, no ingress policy means no ingress pod isolation.
Disclaimer: This behavior might very well be intended, but it could be better explained in the docs for
NETWORK_POLICY_ENFORCING_MODE
.What happened:
If
NETWORK_POLICY_ENFORCING_MODE
is configured tostrict
, if a pod is only targeted with egress-only network policies, ingress is still allowed.For example, given the following network policy:
if there is a pod for which this is the only network policy, the pod will allow inbound network connectivity.
This might be intended, but my expectation was that the
strict
mode disallows all traffic that's not explicitly allowed, and the pod isolation would takepolicyTypes
into consideration, so if there is the only policy type in all network policies for a pod isEgress
, then ingress should be blocked.The docs state:
However, it was my expectation that a egress-only network policy is not qualifying for ingress traffic purposes. At the same time, the Kubernetes docs consider a pod to not be ingress-isolated if there is no Network Policy with the
Ingress
policy type defined.Our use-case:
We would like to disallow ingress by default for all pods without needing to explicitly add a network policy with policy type
Ingress
. It's funny that, out of the box,strict
mode enabled us to do this for pods without network policies, but if we create a network policy that only targets Egress, we accidentally and inadvertently allow ingress to said pod.Environment:
v1.29.8-eks-a737599
v1.18.5-eksbuild.1
Amazon Linux 2
5.10.224-212.876.amzn2.x86_64