Proposed NetworkPolicy best practices

[omkensey]

Following on from my presentation at Helm Summit, I'm working on documenting NetworkPolicy best practices for charts. The basic principles are:

• NetworkPolicy resources should only exist for charts that need them.
• They should be created by default in those charts, with a boolean .create value (defaults to true) to allow the user to prevent their creation.
• There should be a boolean .allowExternal value (defaults to true) 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.

[mattfarina]

/cc @kubernetes/helm-maintainers @kubernetes/charts-maintainers

A couple things come to mind...

• Helm is a package manager rather than a general configuration manager (like chef or puppet). With that in mind, I'd like to keep the focus on the individual packages rather than some broad configuration management (deny by default policy).
• From a security perspective, I like the idea of bringing deny by default for anything that's not expressly needed. And, to have that configurable. But, should it be on by default?

[omkensey]

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?

[andrewhowdencom]

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?

[omkensey]

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.

[prydonius]

Perhaps a default-deny NetworkPolicy could be added the common chart? That way it could be easily included.

[viglesiasce]

I think operating on "least surprise" should be our default guiding principle. To me that means:

1. Open by default, where open means its usable with the instructions listed in its NOTES.txt.
2. Not overloading the service type.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[stale]

This issue is being automatically closed due to inactivity.

[naseemkullah]

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:

  ## Specifies whether a NetworkPolicy should be created
  ##
  enabled: false

  ## The Policy model to apply. When set to false, only pods with the correct
  ## client label will have network access to the port Redis is listening
  ## on. When true, Redis will accept connections from any source
  ## (with the correct destination port).
  ##
  allowExternal: true

Anyone have any suggestions?

[naseemkullah]

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