Jupyter Notebooks provide a pretty easy means for quick, interactive computing and are very frequently used for data science, scientific computing and machine learning workflows. Many use cases of these notebooks like exposing them as a service, internal testing and collaboration and so on... might require organizations to deploy Jupyter Notebook servers in their environment and provide access to users known and unknown. This might also involve using Kubernetes native solutions like [JupyterHub](https://z2jh.jupyter.org/en/stable) for scaling and improved isolation.

However, executing anything through interactive Jupyter Notebooks is essentially "remote code execution" into the environment that runs them. The Jupyter community has itself agreed to the dangerous possibilities and recommended hardening the environment where the notebooks run on [Jupyter's discourse](https://discourse.jupyter.org/t/how-to-control-code-executed-in-jupyter-notebook-e-g-block-malicious-code-execution/12566/2). Thus, measures must be taken to observe and prevent any malicious activity that may happen through these.

KubeArmor is an open source runtime security enforcement engine, currently in CNCF sandbox, meant to monitor and protect workloads both traditional (VMs) and cloud native (containers, K8s). Using eBPF and LSMs (Linux Security Modules) it is able to observe behaviors like process execution, file and network access and so on... for anything that runs on a given system and restrict it through user defined policies.

In this talk, we'll take a look into how administrators/service providers of Jupyter Notebooks and similar interfaces can use KubeArmor's abilities to harden the environment that run these notebooks and restrict what people can do with it, aligning with the principle of least privileged access.