Zero Trust Security For Shared Interactive Computing: Securing JupyterHub With KubeArmor
Rudraksh Pareek (~DelusionalOptimist) |
Description:
Background
Jupyter Notebooks are interactive environments often used for creating simple Data Science, Machine Learning and AI workflows based in Python and other languages. The Jupyter Notebook server is the main component which receives the code and commands, executes them and sends the results back to the interactive UI. However, when running locally the Notebook server runs only in context of a single, trusted user. There are usecases in which these have to be hosted on a common compute and shared amongst multiple users for collaboration, testing, development etc. A tool has been developed by Jupyter community for managing the same - JupyterHub, a Kubernetes friendly solution which can be used for setting up needed environment and serving Jupyter Notebooks to multiple users. Organizations are consuming this for usecases like SaaS offerings, educational purposes, internal collaboration and more. Some of them include - NASA, CERN, UC Berkley and Capital One.
The Problem
There is no doubt that Jupyter Notebooks are essentially "intended remote code execution" tools. Further, JupyterHub based Notebooks might be served to not only trusted but semi-trusted and untrusted users too - which is a big risk and offers a very easy interface for malicious actors to gain access and cause harm to compromised as well as non-compromised users. They may steal important data, degrade overall performance by cryptomining, break out of the isolated environment to compromise the infrastructure itself and so on. The JupyterHub project has accepted this risk too. There is dedicated security documentation as well as recommendations from the community to protect the infrastructure that runs JupyterHub by restricting user behaviour.
The Solution
Many of these problems can be averted if activities happening in JupyterHub environments are monitored and restricted at the system level. In security terms, this is known as runtime security - measures for securing applications/infrastructure while they are executing/running. Further, this should be done for all the users even if they are authenticated by a different mechanism because there is always a chance that they might be compromised. In security terms, this approach is called zero trust.
KubeArmor is an open source CNCF project for runtime security enforcement. At the core, it monitors and restricts behaviours like process executions, file and network accesses and more using Linux primitives like eBPF and LSMs (Linux Security Modules).
KubeArmor was created keeping in mind the difficulties in consuming Linux primitives for runtime security, lack of enough context on workloads and the fragile isolation that containers offer. It is able to protect all sorts of environments ranging from traditional - bare metal, VM environments to modern - Docker or Kubernetes based containers, which makes it perfect for protecting JupyterHub deployments running in VMs (TLJH) or Kubernetes (Z2JH).
Thus, in this session, we'll be taking a look at some of the inherent vulnerabilities of JupyterHub and how can KubeArmor's zero trust approach secure against them.
Layout Starting with a little background on runtime security, understanding it's need in the context of JupyterHub and briefly checking out how KubeArmor does it under the hood, of course with a live demo.
Prerequisites:
Basic idea of what are Jupyter Notebooks and containers
Video URL:
https://drive.google.com/file/d/12pf0eXY0vZ-8aMw-gl3WA9Q7dwnz5cpL/view?usp=sharing
Content URLs:
Speaker Info:
Rudraksh is a generalist software engineer who is currently digging into all things operating systems, networks, cloud and their security. He has maintained a couple of open source projects in the CNCF landscape and currently maintains KubeArmor as a software engineer at AccuKnox. Other than computers, he likes to talk about music of all kinds.