kravciak/pod-runtime-class-policy

A Kubewarden Policy that controls the usage of Pod runtimeClass

Continuous integration	License

This directory contains a Kubewarden policy written using Swift.

The goal

Given the following scenario:

As an operator of a Kubernetes cluster used by multiple groups of user, I want to run untrusted workloads using a more secure container runtime.

Kubernetes has the concept of Container Runtime Interfaces which provides the flexibility to execute workloads using different container engines. Once properly configured, a Kubernetes cluster can run its workloads using different runtimes.

On top of that, each Pod can define which Container Runtime has to be used thanks to the Runtime Class attribute.

For example: trusted workloads could be executed with the "classical" runC, while untrusted ones could be ran using a container engine that has a strong focus on security, like Kata Containers or gVisor.

This policy inspects the AdmissionReview objects generated by the Kubernetes API server and either accept or reject them.

The policy can be used to inspect CREATE and UPDATE requests of Pod resources.

This policy can also be configured to replace a non-valid runtime with a fall-back one.

Configuration

The policy can be configured with the following data structure:

reservedRuntimes:
- runC
fallbackRuntime: containerd-kata
defaultRuntimeReserved: true

This configuration will prevent the usage of the default runtime, plus the explicit request to use the runC one. In these cases, the runtime class will be changed by the policy to be containerd-kata.

Examples

Let's assume our cluster has two Runtime classes defined:

• containerd-runc: containerD uses runC to start containers. This is the default runtime class. Workloads that do not specify a Runtime class will automatically use it.
• containerd-kata: containerD uses the Kata Containers runtime to start containers.

Pod without an explicit runtime configured

The following Pod specification doesn't have any runtime class specified:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

In the majority of the Kubernetes clusters this would imply the usage of the runC runtime.

This can be prevented by using the following configuration:

reservedRuntimes:
- runC
defaultRuntimeReserved: true

It's also possible to have the policy accept a mutated version of the request:

reservedRuntimes:
- runC
fallbackRuntime: containerd-kata
defaultRuntimeReserved: true

This would lead to the creation of the following Pod:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  runtimeClassName: containerd-kata
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

Pod with an invalid runtime

This Pod specification has instead the runtime class set to be containerd-runc:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  runtimeClassName: containerd-runc
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent

This Pod can be automatically mutated using the following configuration:

reservedRuntimes:
- runC
fallbackRuntime: containerd-kata
defaultRuntimeReserved: true