If you are interest in containers and security, you have probably already heard about the isolation concerns regarding containers. The kernel sharing between the containers and the host makes containers very lightweight, but at the same time it creates a broad attack surface. A simple example is what happens if a container manages to create a panic in the kernel. This affects the entire host and the other containers running on it. A very interesting post about the security concerns in containers can be found in this blog.
Kata containers aims to solve some of the security lacks of standard containers by starting the containerized application inside a KVM guest. The idea could initially sound confusing. Why don’t we simply use VMs rather then container? Well, Kata containers combine the benefits from both technologies. As they state on their website ‘The speed of containers, the security of VMs’. The containerized application is started in a minimal VMs. The goal is to minimize the boot time and isolate the workload with a guest kernel, but at the same time keep the agility of the containers. One of the huge benefits in using container is the packaging. All the dependencies needed by the application are delivered inside the container image. Kata takes advantages of the container usability but improving the isolation.
Since mid of December, they have merged the IBM Z support! You can use Kata containers to improve the container isolation on the mainframe. You can follow their online documentation to install the Kata components.
In my opinion, a very positive aspect of the Kata project is their completeness. They can work with Docker, but also with other container engines like cri-containerd and cri-o. The Kubernetes community introduced the CRI interface to be able to plug various container engines. Up to now, the Kata runtime can be used with Kubernetes only together with either cri-o or containerd. A deep dive in container engines could be found in this article.
The idea to start a containerized application inside a KVM guest is not new. A previous project call runv developed this idea. Another project started by Intel call Clear Container was based on the same concept. Today runv and Clear Container have been deprecated and merged inside the Kata project. On Linux on IBM Z, runq has been successfully used in production to deploy IBM Blockchain. Runq favors the simplicity over the number of features. One of the limits of runq consists that only a single containerized application can be started inside the guest. This limitation prevents runq to be used together with Kubernetes. Additionally, runq is only available for Linux on IBM Z and x86, while the Kata projects support the major architectures such as x86, ARM, PowerPC and IBM Z.
Kata containers can be used in parallel with standard container. CRI interface allows to define a pod as trusted or untrusted (see this article how that is done with cri-o).
I hope you got curious about Kata!