investigate gVisor support

[bcressey]

We've heard from customers that they're interested in gVisor support for sandboxing containers.

Some areas to investigate:

• disk footprint of solution
• potential for integration into settings API
• support for primary architectures (x86_64 and aarch64)
• performance overhead
• interoperability with SELinux

[igorantunes1984]

@gregdek When do you plan to start to tackle this feature?

[gregdek]

You'll have to ask @bcressey -- I'm no longer with the org. :) (Hi Ben!)

[igorantunes1984]

@gregdek thank you 👍
@bcressey same question as above. Is there a plan and timeline to tackle this issue?

[bcressey]

@gregdek - Hi! 😀

@igorantunes1984 - this isn't being actively worked on right now, and isn't on the roadmap for the year. That said, we're happy to collaborate if you have any interest in contributing.

Any or all of these would be helpful:

• config file examples of integrating gVisor with containerd
• notes on the architecture support and binary size
• adding the package build file (might be blocked on Go Modules in packages #2052)
• integrating it into the containerd or Docker configs

Even general thoughts on the "right" experience for using gVisor would be helpful. Should there be an API setting, so that all containers default to Visor? Or is the Kubernetes support for selecting a custom runtime class sufficient?

In recent months for NVIDIA builds, we've defined custom runtimes in the containerd-cri config (in #1799) and the Docker config (in #2097) so there are some examples of doing something similar in the tree now.

[igorantunes1984]

Hi @gregdek

Thank you for the information.
Can't promise that I will be help to contribute much but I will try :)

Regarding the experience and keeping in mind the reduced attack surface and that gVisor only implements part of the kernel in user space, I believe that when gVisor becomes available it should be off by default with settings to:

1. Enable gVisor and allow it to be chosen via k8s
2. Enable gVisor and make it the default runtime
3. Default back to containerd runtime
4. Disable gVisor

Hope this helps :)

[pietro]

Some info just in case it helps move this along:

disk footprint of solution

Getting the files described in the installation docs:

x86_64

$ wget -q https://storage.googleapis.com/gvisor/releases/release/latest/x86_64/runsc https://storage.googleapis.com/gvisor/releases/release/latest/x86_64/containerd-shim-runsc-v1
$ du -sh *
24M	containerd-shim-runsc-v1
38M	runsc

aarch64

$ wget -q https://storage.googleapis.com/gvisor/releases/release/latest/aarch64/runsc https://storage.googleapis.com/gvisor/releases/release/latest/aarch64/containerd-shim-runsc-v1
$ du -sh *
23M	containerd-shim-runsc-v1
37M	runsc

support for primary architectures (x86_64 and aarch64)

Yes, both listed in installation docs.

performance overhead

https://gvisor.dev/docs/architecture_guide/performance/

potential for integration into settings API
and
interoperability with SELinux

are two areas I haven't looked into.

Another detail is that gvisor uses bazel as build tool.