-
Notifications
You must be signed in to change notification settings - Fork 16.8k
Proposed NetworkPolicy best practices #4067
Comments
/cc @kubernetes/helm-maintainers @kubernetes/charts-maintainers A couple things come to mind...
|
I think default-deny should be off by default, actually -- it would violate the principle of least astonishment if users were suddenly cut off from their apps without asking to be. Understood on packaging vs. general config. Maybe the thing to do, then, is create allow policy rules by default (which won't really do anything if nothing is denied, but won't hurt anything either), and put something in NOTES.txt about how to enable default deny with a policy created through kubectl? |
we already have a kind of proxy external requirement with the service type either being "NodePort" or "LoadBalancer". maybe we can determine the default from this? |
I thought about that -- it makes sense, but 1) it might make it harder to reason about the chart and 2) there might be cases where either a NodePort'ed app needs to not allow external access or a ClusterIP'ed app needs to allow it. I need to play around with each case just to see how I feel about it before I have a strong opinion either way though. |
Perhaps a default-deny NetworkPolicy could be added the common chart? That way it could be easily included. |
I think operating on "least surprise" should be our default guiding principle. To me that means:
|
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
This issue is being automatically closed due to inactivity. |
I'm looking for a better way to add network policies to charts, particularly that we can now specify namespaceSelector and podSelector in combination. charts in stable repo all seem to follow this convention, but it's not fine grained enough for selectors:
Anyone have any suggestions? |
This needs to be reopened as we have not solved allowing some pods from other namespaces as per https://github.com/ahmetb/kubernetes-network-policy-recipes/blob/master/07-allow-traffic-from-some-pods-in-another-namespace.md CC @scottrigby |
Following on from my presentation at Helm Summit, I'm working on documenting NetworkPolicy best practices for charts. The basic principles are:
.create
value (defaults totrue
) to allow the user to prevent their creation..allowExternal
value (defaults totrue
) which controls whether access is allowed from outside the cluster.I also want to address default deny. This is a network security best practice generally -- anything not specifically allowed is denied. At Summit I proposed that NetworkPolicy-enabled charts should include a default-deny policy template that is disabled by default, to allow users to easily implement default-deny by simply turning it on in any chart that has NetworkPolicy in it. But after thinking about it some more, I wonder if it wouldn't be better to actually have a chart that is just a default-deny NetworkPolicy. That would make it easier to install if the user wants to implement and manage such policy via Helm but doesn't need to install any NetworkPolicy-enabled charts. It would also make it easier to remove if they need to debug something. It would, however, require the user to take an extra step which might get overlooked. So I'm filing this issue to gather opinions.
The text was updated successfully, but these errors were encountered: