jupyterhub / binderhub

Run your code in the cloud, with technology so advanced, it feels like magic!
https://binderhub.readthedocs.io
BSD 3-Clause "New" or "Revised" License
2.58k stars 390 forks source link

Implement NetworkPolicy #362

Open minrk opened 6 years ago

minrk commented 6 years ago

To better lockdown the internal network, we should start instituting NetworkPolicies.

In particular, these allow us to set ingress and egress policies for which pods should have access to what. Egress policy support requires calico 2.6.1, which should be new in the latest GKE release (1.8.4-gke.0).

Starting this issue for sketching out what our inter-connect network needs really are. For various services:

user pods:

builds (docker-in-docker, user build code):

binder:

hub:

What about data collection services, such as prometheus?

We should figure out the best way to express these requirements, especially in a way that allows deployments to add additional services permissions. That probably means using label-selectors to allow access to pods, and making sure that those label selectors are easy to apply where they are needed.

consideRatio commented 3 years ago

The Z2JH network policy system is quite thorough and tested at this point. I suggest we mimic the configuration options from that Helm chart. In practice we should define a NetworkPolicy for each of our BinderHub specific workloads - the binderhub pods and the build pods I think.

For details about the z2jh implementation the following documentation and such is relevant:

  1. A NetworkPolicy definition, we can inspect the hub pod's netpol resource
  2. Documentation about the netpol configuration, which is very similar for all netpols in z2jh's workloads (hub, proxy.chp - proxy pod, proxy.traefik -autohttps pod, scheduling.userScheduler - user-scheduler pod).