why unsupported network policies are converted to deny-all
Closed this issue · 7 comments
I ran some workload that has an unsupported networkpolicy, it is converted to deny-all per this line. This makes debugging difficult. Would it make sense just to drop the unsupported networkpolicy instead of deny all?
@deads2k
I1031 14:34:49.442501 4018 networkpolicy.go:482] Unsupported NetworkPolicy xxxx (named port values ("metrics") are not implemented); treating as deny-all
for the specific error case (named port), per API spec, port can be both numerical and named
https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/#networkpolicyport-v1-networking-k8s-io
cc @danwinship
/assign @danwinship
It turns into deny-all so that you'll notice that it's not working faster (since we can't easily reject the policy at creation time).
If a customer needs support for policies with named ports, you can link a support case to https://bugzilla.redhat.com/show_bug.cgi?id=1711602 or otherwise comment there. But the code is working as intended right now.
/close
@danwinship: Closing this issue.
In response to this:
It turns into deny-all so that you'll notice that it's not working faster (since we can't easily reject the policy at creation time).
If a customer needs support for policies with named ports, you can link a support case to https://bugzilla.redhat.com/show_bug.cgi?id=1711602 or otherwise comment there. But the code is working as intended right now.
/close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.
@danwinship the issue is not so much the lack of support for named ports (I understand that is a feature request), but when someone brings yaml that works (or at least doesn't break) on upstream kubernetes, now it cripples the network on OpenShift. This is conflicting behavoir, and I would say is a bug. Even silently dropping that policy would be less confusing than DENY-ALL.
Even silently dropping that policy would be less confusing than DENY-ALL.
Silently dropping the policy would be a security hole; the user has requested that we limit access to those pods. It's possible that they wouldn't want the pods to be there at all if they can't be protected.
However, there is no need to turn it into a full default-deny for the whole Namespace. #69 changes the behavior so that we just ignore the unrecognized rule. However, note that this isn't really going to do what you're hoping. The NetworkPolicies will still be selecting those pods, but now it won't have any rules allowing access to them. So you're still going to need to create additional NetworkPolicies to allow access to those pods.