Container Hardening

Container Hardening

1. Introduction

The use of containers increases overall flexibility, and it also introduces additional management requirements and security issues. In a virtual machine, all components are in the same place, and the virtual machine can be managed and protected as an independent entity. Different from this, for container based applications, a series of functions that make up the application are loosely coupled together, so we need to manage and protect each one separately.
If the security protection of the underlying platform is not in place, then the security of all containers built on the basis of it cannot be guaranteed. The reverse is true. Assume that a container image has full superuser rights. Because the container needs to continuously interact with the underlying platform, an intruder who has access to the container can theoretically break through the underlying platform through the containerized environment and obtain the access rights of the underlying platform.
This paper discusses three different security methods, including when they are sufficient and when they might not be.

2. Three methods to harden container

(1) gVisor

gVisor abstracts a layer between user state and kernel state and encapsulates it as an API, similar to a user mode kernel, so as to achieve isolation.

gVisor is a user mode kernel written in golang, or it could be seen as a sandbox technology. It mainly implements most system calls. It runs between the application and the kernel, providing isolation for them. The gVisor runtime consists of multiple sandboxes, which collectively cover one or more containers. By intercepting all system calls from the application to the host kernel, and using sentry in user space to process them, gVisor acts as the guest kernel and can be regarded as a collection of VM and guest kernel without virtualization hardware conversion. It has powerful memory management and has been proven by Google for many years in a production environment.
Because gVisor intercepts all system calls and processes them. The architecture of gVisor will cause more overhead when it communicates with the kernel. Therefore, it is not suitable for applications that need to call system calls frequently. When choosing whether to use gVisor or not, we need to consider the problem of performance loss. On the other hand, the compatibility of gVisor is not good. Currently, gVisor can only run on new versions of Linux and only supports 64 bit systems.

(2) KubeVirt

KubeVirt is a RedHat open source project that runs virtual machines as containers. It is a kind of k8s add-on, which uses k8s CRD to add resource type virtual machine instance (VMI), and uses container’s image registry to create virtual machine and provide VM lifecycle management.

KubeVirt technology can meet the needs of development teams that have adopted or want to adopt kubernetes, but they have existing virtual machine based workloads and cannot easily make them as container. More specifically, the technology provides a unified development platform on which developers can build, modify and deploy applications in application containers and virtual machines that reside in the common shared environment. Relying on existing virtual machine based workloads, teams have the right to quickly make applications as container. By placing virtualization workloads directly into the development workflow, teams can decompose them over time while still using the remaining virtualization components on demand. KubeVirt could help teams to use Kubernetes to manage virtual machines for impractical-to-containerize apps, combine existing virtualized workloads with new container workloads on the one platform and develop new microservice applications in containers that interact with existing virtualized applications.
KubeVirt’s management of virtual machines is not limited to the pod management interface, but it cannot use the RS DS deployment and other management capabilities of pod. It also means that if KubeVirt wants to make use of the pod management capability, it has to implement it independently. The compatibility of kubevirt is not good. Currently, the supported runtimes are docker and runv.

(3) Kata Container

Kata container’s container runtime is implemented with hypervisor and hardware virtualization, just like virtual machine. So every pod of Kata container like this is a lightweight virtual machine with a full Linux kernel. So Kata container can provide strong isolation just like VM, but because of its optimization and performance design, it also has the agility comparable to the container.

Kata container is more secure than traditional containers. Because it uses hardware virtualization to achieve container isolation. Each container / pod is based on a separate kernel instance as a lightweight virtual machine. Since each container / pod runs on a separate virtual machine, they no longer get all the permissions from the host kernel.
But its structure also causes it to start slower than the traditional container. It also cannot run in a virtual machine, because it already uses virtualization technology. In addition, although it optimizes the kernel of the system to provide the same performance as the traditional container, it also increases the maintenance cost of the kernel.

3. Citations

[1] Gvisor.dev. 2020. What Is Gvisor? - Gvisor. [online] Available at: https://gvisor.dev/docs/ [Accessed 16 October 2020].
[2] The KubeVirt.io website team, 2020. Kubevirt.Io. [online] KubeVirt.io. Available at: https://kubevirt.io/ [Accessed 16 October 2020].
[3] GitHub. 2020. Kubevirt/Kubevirt. [online] Available at: https://github.com/kubevirt/kubevirt/blob/master/docs/architecture.md [Accessed 16 October 2020].
[4] GitHub. 2020. Kata-Containers/Documentation. [online] Available at: https://github.com/kata-containers/documentation/ [Accessed 16 October 2020].
[5] Katacontainers.io. 2020. Learn About The Kata Containers Project. [online] Available at: https://katacontainers.io/learn/ [Accessed 16 October 2020].