GP - Fotolia

Tip

Kata Containers, gVisor offer more secure container strategies

Kata Containers and Google gVisor present different approaches to using VMs for container security. Evaluate their advantages to get insight into the future of container security.

Kata Containers and Google gVisor present two approaches to addressing container security issues that balance the speed of containers with the safety of VMs.

Containers are fast, lightweight instances that can benefit a variety of workloads, especially ones that include microservices and serverless applications. Organizations that implement containers on bare-metal hardware introduce security risks because containers can expose the underlying infrastructure, which leaves the entire platform vulnerable to attack.

To address these security issues, many data centers run containerized workloads in VMs so they can take advantage of better security and isolation. Unfortunately, this approach can also result in inflexibility and inefficient resource utilization, which undermine some of the reasons to use containers.

Several services have emerged to secure container environments and balance bare-metal and VM deployments while keeping them flexible and lightweight. Kata Containers and Google's gVisor are leading examples that promise to streamline and secure container deployments, but each takes a different approach.

Kata Containers uses VMs to bolster container security

Kata Containers, launched in December 2017, is an open source project that the OpenStack Foundation manages and makes available under the Apache 2.0 license. The project uses virtualization to provide a secure environment in which to run containers, while also delivering higher resource utilization and more simplicity than traditional VM implementations.

Kata Containers hosts each container in a dedicated, lightweight VM that gets its own kernel, isolated network, memory and I/O resources. The project combines technologies from Hyper runV and Intel Clear Containers to address container security issues without the overhead of a full VM.

containers vs. VMs
Figure A. Review the differences between containers and VMs.

Hyper runV is a hypervisor-based implementation of the Open Container Initiative (OCI) runtime. The OCI runtime functions similarly to runC, a portable container runtime that Docker containers use. However, runC relies on cgroups and Namespaces to implement container images, whereas runV uses a hypervisor.

Clear Containers started with each container running in a lightweight VM. Clear Containers is based on Intel Virtualization Technology, and it provides an open source service to securely run containerized workloads. Clear Containers is also OCI-compatible, so it's interoperable with container environments such as Docker and Kubernetes.

The Kata Containers project uses the best features of Hyper runV and Clear Containers to create a service that addresses the container security issues that come with running them on bare-metal hardware. The project is OCI-compliant, so it's also interoperable with both Docker and Kubernetes, which enables organizations to securely implement it without rebuilding existing containers.

Currently, Kata Containers only supports the Linux OS for both the host and guest OSes, with out-of-the-box support for distributions such as Fedora, CentOS 7 and Clear Linux. Data centers can only run Linux containers in this case, which is fine for most container workloads because the majority of them use Linux.

VMware and Microsoft offer alternatives

Kata Containers is similar to VMware's vSphere Integrated Containers (VIC). VIC also runs each container in a lightweight VM. However, VIC creates these VMs in a virtual container host (VCH), which is a logical collection of processor, memory and storage resources. The VCH can contain multiple VMs that provide access to advanced vSphere security, isolation, availability and performance features.

VIC also has much more specific installation requirements, including different components with different specifications. For example, admins must install the VCHs on a VMware vCenter Server instance or a stand-alone ESXi host. Additionally, admins must attach all the ESXi hosts in vCenter Server clusters to the image and volume data stores, and they must have access to shared storage so the VCHs can use more than one host in a cluster. VIC also only supports Linux containers.

Microsoft's Hyper-V containers also fall into this category. Again, each container runs in a special optimized VM and each VM hosts one container. The VM retains just enough OS functionality to run the container, which results in shorter startup time and a smaller footprint. Hyper-V containers also support a special booting process that can reduce startup times even further.

Although Hyper-V containers must run in a Windows environment, they support both Windows and Linux containers, something neither Kata Containers nor VIC do. However, Kata Containers isn't tied to a particular vendor, as is the case with Hyper-V containers and VIC, so all that's necessary to deploy Kata Containers is the right Linux distro.

Google gVisor provides a new container security approach

Kata Containers and similar services offer numerous advantages over running containers in full VMs. Because they use lightweight VMs, each container generates a smaller footprint, which results in higher resource utilization. These services also simplify container implementation by eliminating much of the administrative overhead from traditional VMs.

Despite these advantages, even lightweight VMs represent additional overhead when compared to running containers on bare-metal hardware. For this reason, Google created gVisor, a sandboxed container runtime that provides an isolated boundary between the container application and the host OS without requiring a VM.

Like Kata Containers, Google gVisor is OCI-compliant and integrates with Docker and Kubernetes. However, gVisor is more flexible and has an even smaller footprint. The gVisor core runs as an unprivileged user space process that supports most Linux system calls. To create the sandbox, gVisor isolates the workloads from the host OS by intercepting those calls and creating an environment that gets its own kernel and set of virtualized resources.

Google based gVisor on technologies already in production and made the service available as an open source project on GitHub under the Apache 2.0 license. The service only supports Linux for both the host OS and guest OS, which means it only supports Linux containers.

Although gVisor is more lightweight than Kata Containers, gVisor can't run all the Linux applications because it doesn't support all the system calls in the Linux system API. Currently, the gVisor project on GitHub shows that only 20 applications and images have been tested.

Containers offer a multitude of benefits, but organizations must have a plan for container security before they can support production workloads. Many data centers deploy containers in VMs to address this.

Virtualization provides a tried-and-true approach toward supporting containerized workloads, and organizations can deploy them with their current infrastructure. However, these full VMs can be inflexible and inefficient, which defeats much of the purpose of using containers.

Services such as Kata Containers employ dedicated, lightweight VMs and can go a long way toward addressing container security, but these VMs still come with overhead. For this reason, many organizations are watching the gVisor project to see whether it will prove a viable alternative to current container tools.

GVisor avoids the VM overhead altogether, but the service isn't as mature as other options. Even so, gVisor has a great deal of promise -- enough for organizations across the container industry to take it seriously.

Dig Deeper on Containers and virtualization