Installation in Kubernetes Clusters and privileged: true

[HansKre]

We tried to understand Installation process as described in install-k8s. However, what we are struggeling with is that it applys a sysbox-install.yaml which is setting the securityContext as privileged: true

securityContext:
          privileged: true

Our question is, how this makes sense from a rootless containers perspective.

If you could help understand, would be highly appreciated!

[ctalledo]

Hi @HansKre, thanks for looking into Sysbox.

Our question is, how this makes sense from a rootless containers perspective.

The sybox-deploy-k8s daemonset's only job is to install Sysbox on the K8s node. In order to do this, it must have root privileges on the node, as it needs to "drop" CRI-O + Sysbox on the node and then configure the K8s Kubelet accordingly (these are all privileged operations). Once it does this, the daemonset sits idle doing nothing. It's helpful to keep around in case the K8s node is reprovisioned (so it can re-install Sysbox), but otherwise it does nothing else.

Now Sysbox itself is an alternative runc, and it runs with root privileges on the node (just like Kubelet, CRI-O, or the regular runc runtime). However, what makes Sysbox different is that all containers deployed with it run within a Linux user-namespace (i.e., the containers are rootless) and resemble a VM-like environment, such that they can run software like Docker, systemd, k8s, k3s, etc., seamlessly. Sysbox takes care of setting up the container the proper way, and in fact actively monitors some operations inside the container such as accesses to /proc and /sys, a few system calls, etc.

Hope this helps, let me know if you have any questions.

Note that it's always possible to set up a K8s node with Sysbox without using sysbox-deploy-k8s. But it would require that you manually install CRI-O, Sysbox, and reconfigure the Kubelet on the node. It's cumbersome and tricky, which is why we created the sysbox-deploy-k8s daemonset to automate and simplify the process.

[rodnymolina]

@HansKre, that's right, we make use of a privileged container but only for the purpose of installing the Sysbox artifacts (binaries + dependencies) in the host file-system. We do need these privileges for our installation daemonset to be able to drop these files. See that this doesn't apply to the Sysbox containers themselves, which execute without any of these special privileges.