To follow up with this issue: https://github.com/jupyterhub/zero-to-jupyterhub-k8s/issues/1615
I’m opening this thread to centralize information about how JupyterHub on k8s could be made more secure in scenarios where users are considered fully untrusted in the threat model.
Currently we have multiple potential solutions that yet have to mature:
- Kata Containers (used in production, but still maturing)
- gVisor (experimental)
- unprivileged kubernetes: usernetes and conference talk video
- more carefully written and smaller container runtimes (smaller means less attack surface and easier security audit): cri-o
- CPU’s MMU based kernel data structure isolation for enhanced container security: https://fosdem.org/2020/schedule/event/kernel_address_space_isolation/
Right now, none of these solutions are either production-ready or usable with JupyterHub. Some solutions are only partial, for example, using cri-o would not negate the need for better isolation, as that’s provided by the kernel.
KubeVirt is probably the most production-ready solution but then it might not be useful to use Kubernetes at all for the deployment.
Kata Containers does not support network namespace sharing, because a single network namespace can’t be shared across VMs, as it’s a kernel abstraction. Note that network namespaces are different than a private network. A network namespace contains interfaces, sharing network namespaces means sharing interfaces.
Performance measurements would also be interesting for production-readiness ;
- Kata Containers has an experimental virtio block based backend that should offer much better performance.
- gVisor has the same disk performance issue
Research on this topic is far from complete, so please comment with any new information or emerging solutions!