Hands-on Lab·Certified Kubernetes Security Specialist
Sandboxed Containers with gVisor and RuntimeClass
The previous guide ended with two tenants sharing one kernel. This one gives a Pod a kernel of its own - four lines of RuntimeClass, one line in the Pod spec, and a proof that fits on a single line of output.
Microservice Vulnerabilities Guide 23 of 40 Advanced
- Kubernetesapiserver v1.36.4, kubelet v1.36.3
- Runtimecontainerd 2.2.6
- CNICilium 1.18.1
- Built withkubeadm v1.36.3
- TimeAbout 16 min
containerd on these nodes already has a runsc handler configured. Kubernetes cannot use it until a RuntimeClass names it, which is the entire integration.
- Host kernel7.0.0-29
| Server Name | IP Address | OS | Roles | CPU | RAM | HDD |
|---|---|---|---|---|---|---|
| CKA6001 | 192.168.0.46 | Ubuntu 26.04 LTS | Control Plane Node (tainted NoSchedule) | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE01 | 192.168.0.47 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
| CKA6001-NODE02 | 192.168.0.48 | Ubuntu 26.04 LTS | Worker Node | 2 Core | 4 GB | 50 GB |
This guide includes
Use this when two tenants must not share a kernel. This matters because ordinary containers do share one - and a RuntimeClass is four lines that changes which kernel a Pod actually gets.
- finding no RuntimeClass in the cluster, and two handlers already present on the node
- naming one with four lines of RuntimeClass, and a single line in the Pod
- proving it by reading the kernel itself, three times over
- contrasting with an ordinary container, and being clear about what this is not
Before you start
- guide 22 - the boundary this one extends.
-
What the runtime can already do
-
Name it, and use it
-
The proof, which is the kernel itself
-
The contrast, and what it is not