Continuous integration | License |
---|---|
This policy was originally written using Swift. But it has been rewritten with Rust due the maturaty of SwiftWasm compiler project. You can still find the old implementation in the swift-implementation branch
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.
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
.
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.
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
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