traefik
Add network policy as "non-critical feature" for use on clusters with deny all policy
Welcome!
- [X] Yes, I've searched similar issues on GitHub and didn't find any.
- [X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.
What did you expect to see?
Context:
I am running the Traefik Helm Chart on a cluster that has a deny all network policy by default. To enable network traffic for Traefik, I patched the Helm chart and included the optional feature to deploy a network policy.
Expectation:
I am wondering whether it makes sense to include that feature in the official Helm chart. The plus of having this in the Helm chart vs. deploying it separately is that you can pull the ports from the values.yaml. Therefore, the Traefik deployment and the network policy are always in sync.
One can argue whether this is a "specific use case" (as per contribution guideline) or not. I think not. Especially in the light of increasing security requirements, a fine-grained network policy might be something that users want to deploy easily. What do you think? I can open a PR for this if the feature finds favor.
The configuration of a NetworkPolicy allowing traffic to ingress controllers would depend on your SDN (if using NodePorts/LoadBalancer services, Calico would NAT with network addresses matching host subnets, OVS with the first host address in host subnets) or usage of hostNetwork (OVS has netnamespaces, while ipBlocks could make sense). The only configuration that would fit all use cases would be to create a policy allowing any communications to Traefik.
Creating your first NetworkPolicy in a namespace, when your SDN offers support for this, implies that the default policy in your namespace changes from allow-all to deny-all. Any communications that is not allowed by an existing policy is implicitly denied.
Thus, we should probably not create a NetworkPolicy, in a namespace that doesn't already have one: if other services are located in that namespace, we're likely to break something (say someone deploys Traefik in kube-system) Or, we should install a NetworkPolicy that allows any communications, regardless of the target Pod, Traefik or not. And then, we may be defeating existing configurations.
I'm not sure. We could add one up. Though dealing with NetworkPolicies, I would first suggest you consider your options, based on your context. Allow-all would sure work everywhere, but I would not recommend it.
Good point! I did not consider the fact that the network policy might have implementation specific aspects. After rechecking the Kubernetes docs on Network Policies I think that some of your doubts are unfounded (e.g. change from allow-all to deny-all: Other pods in the namespace that are not selected by any NetworkPolicy will continue to accept all traffic.).
But in general I agree that there might be unwanted side effects and I am not enough of an network/K8s expert to come to a final conclusion. I will keep this open for some more days to see if sb else has some opinion on it and then close it. Thanks!
Other pods in the namespace that are not selected by any NetworkPolicy will continue to accept all traffic.
I'ld have to check. I've been using them for a while now (1.11), and when I migrated: I had to proceed one namespace after the other. Just going one app after the other broke communications for other unrelated pods within that namespace.