Sandbox runtimes and CIS checks: gVisor, Kata, kube-bench

runc shares the host kernel with every container. That is fast. It is also the blast radius when a container escape works. gVisor and Kata sit under a RuntimeClass so you can run the sensitive pods in a tighter sandbox. kube-bench is the separate question: is the node itself configured like CIS says it should be.

RuntimeClass

Kubernetes does not install a sandbox for you. It only names a containerd handler.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: gvisor
handler: runsc

apiVersion: v1
kind: Pod
metadata:
  name: gvisor-pod
spec:
  runtimeClassName: gvisor
  containers:
  - name: app
    image: nginx:1.20

Priority is pod runtimeClassName, then whatever containerd uses as default (usually runc).

kubectl get runtimeclass
kubectl describe pod <name> | grep "Runtime Class"

gVisor

gVisor (runsc) is a user-space kernel. Syscalls from the app hit gVisor first, not the host kernel. Attack surface drops. Overhead goes up.

Install runsc, then add a runtime in /etc/containerd/config.toml:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runsc]
  runtime_type = "io.containerd.runsc.v1"

Optional /etc/containerd/runsc.toml knobs: platform = "ptrace" (compatible) vs "kvm" (faster), network = "sandbox" vs "host". Restart containerd after you edit.

If the pod never starts, check that runsc is on the node PATH, that the RuntimeClass handler matches the toml key, and kubectl describe for the sandbox error.

Kata Containers

Kata puts the pod in a lightweight VM. Isolation is stronger than gVisor. Cost is a guest kernel per pod, slower boot, and a hard requirement for hardware virtualization.

egrep -c '(vmx|svm)' /proc/cpuinfo
lsmod | grep kvm
kata-runtime --version
/opt/kata/bin/kata-runtime kata-check

containerd handler is usually kata, config at /opt/kata/share/defaults/kata-containers/configuration.toml. Nested virtualization in a cloud VM often fails kata-check. Do not pick Kata for a node that cannot run VMs.

RuntimeClass:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata
handler: kata

kube-bench

kube-bench runs the CIS Kubernetes Benchmark against the node you are on. It wants host PID and the real /etc/kubernetes paths, not a random developer laptop.

kube-bench
kube-bench --targets master
kube-bench --targets node
kube-bench --targets etcd
kube-bench --check 1.2.1
kube-bench --json --outputfile results.json

As a Job on a control-plane node, mount /etc/kubernetes read-only and set hostPID: true. Read kubectl logs on the job. Fix the failed checks in the static pod manifests, then scan again.

gVisor when you want kernel isolation without a VM. Kata when you need a VM and the hardware can do it. kube-bench for the node, not the workload.