Challenge, Easy,  on  Kubernetes, Security

Verify Kernel Isolation Between Kata Containers and runc Using RuntimeClass

Omkar Shelke
by  Omkar Shelke

Scenario

The cluster has two Kata runtimes available via RuntimeClass:

  • kata-clh — uses Cloud Hypervisor as the VMM
  • kata-qemu — uses QEMU as the VMM

Your task is to deploy Pods using each runtime and prove kernel isolation by comparing the kernel version reported inside each Pod against the runc Pod kernel, saving each output to a file.

Task

Deploy three Pods in the default namespace:

  • nginx-runc — uses the default runc runtime.
  • nginx-clh — uses runtimeClassName: kata-clh
  • nginx-qemu — uses runtimeClassName: kata-qemu

All three Pods should use the image nginx:stable.

After all Pods are Running, run uname -a inside each Pod and save each output to the following paths:

SourceOutput File
nginx-runc/home/laborant/nginx-runc/runc-pod.txt
nginx-clh/home/laborant/nginx-clh/clh-pod.txt
nginx-qemu/home/laborant/nginx-qemu/qemu-pod.txt

Verify that:

  • The nginx-clh and nginx-qemu Pods report a different kernel version from nginx-runc — this is the guest VM kernel bundled with Kata Containers
  • The nginx-clh and nginx-qemu Pods report the same guest kernel version as each other
Hint

A RuntimeClass is a cluster-scoped resource that maps a name to a container runtime handler. Check the available RuntimeClasses before creating Pods:

kubectl get runtimeclass

Reference a RuntimeClass in a Pod spec using the runtimeClassName field:

spec:
  runtimeClassName: kata-clh

If runtimeClassName is omitted, the cluster default runtime (runc) is used.

See the official docs: Runtime Class

Test Cases

How to Author Challenges on iximiuz Labs

Instead of providing a subpar online editing experience, iximiuz Labs offers a helper CLI tool called labctl, allowing you to use your favorite text editor (or a full-featured IDE) to write content from the comfort of your local machine.

Install labctl CLI

curl -sf https://labs.iximiuz.com/cli/install.sh | sh

This will download and install the latest version of the labctl CLI. You only need to do this once per workstation.

Authorize labctl

labctl auth login

This will open a browser window asking you to authorize labctl to access your account. You need to do it after a fresh install of labctl and repeat it whenever the auth session expires.

Pull challenge content

labctl content pull challenge verify-kernel-isolation-between-kata-containers-and-runc-5efb12c8

This will create a local copy of the challenge content in a directory named verify-kernel-isolation-between-kata-containers-and-runc-5efb12c8. You only need to do this once per challenge.

Stream your changes

labctl content push -fw challenge verify-kernel-isolation-between-kata-containers-and-runc-5efb12c8

Run this command in a separate terminal to continuously upload your changes to the server while editing the challenge in your favorite text editor or IDE.

You can also use labctl to create, list, and delete your content. Learn more about the available commands: labctl content --help

Start challenge