containerd: What You Should Know

What is containerd?

containerd is a container runtime that manages the lifecycle of a container on a physical or virtual machine (a host). It is a daemon process that creates, starts, stops, and destroys containers. It is also able to pull container images from container registries, mount storage, and enable networking for a container.

containerd was created by Docker and donated to the Cloud Native Computing Foundation (CNCF). It is a subset of its original Docker Engine, which has most of Docker’s functionality for running containers, handling storage, and managing images, but does not have many developer-facing features, making it suitable for large-scale use as part of container orchestrators like Kubernetes. Docker Engine runs containerd behind the scenes.

Docker Engine is an example of a high-level container engine primarily used by developers, while containerd is an example of a low-level container engine, with only basic functionality, suitable for use by automated mechanisms.

containerd fully supports standards established by the Open Container Initiative (OCI), an open governance organization focused on container best practices. It also supports the container runtime interface (CRI), a Kubernetes specification developed to allow multiple container runtimes to operate as part of a cluster. Kubernetes can use containerd, and other low-level container runtimes supporting OCI, to run containers on Kubernetes nodes. 

This is part of our series of articles about container platforms.

In this article:

• containerd vs Docker
• containerd vs CRI vs OCI vs CRIO vs RUNC
• containerd Features
• containerd Security Best Practices
• containerd Security with Aqua

containerd vs Docker

Docker provides a broad set of technologies used to run and manage containers. One of those technologies is Docker Engine, a full-featured container runtime with advanced developer tools.

containerd is also a container runtime, based on Docker technology. You can use containerd on its own, as a bare-bones container runtime solution. Additionally, newer versions of Docker Engine use containerd behind the scenes. 

The Docker Engine command line interface (CLI) allows you to interact with the underlying container runtime using commands. For example, the docker run command instructs the container runtime to create a container based on a specified image. Behind the scenes, containerd takes over, downloads the relevant container image, and creates a container from that image.

containerd vs CRI vs OCI vs CRIO vs RUNC

Here is how containerd compares to a few other common container engines:

• Container Runtime Interface (CRI)—this is the API used by Kubernetes to control container runtimes. The CRI API describes how Kubernetes should interact with a container runtime. So while containerd is a specific container runtime, CRI is an interface that can work with any supported runtime. Learn more in our guide to Container Runtime Interface ›
• Open Container Initiative (OCI)—this is a collaborative effort for maintaining a container image specification format. OCI images have a standard format and any container runtime that supports OCI can run them. So while containerd can run container images, OCI is a format for describing how container images are structured.
• CRI-O—this is a container runtime with similar functionality sets as containerd. CRI-O pulls containers from a registry, manages their lifecycle, and executes a low-level runtime (runc) to run their processes. CRI-O was developed from the outset as a container runtime for Kubernetes. 
• runc—this is an OCI-compatible low-level runtime. It provides basic functionality such as interacting with Linux kernel features or managing namespaces and control groups. It does not provide a full featured CLI or utilities for developers. Containerd uses runc to launch containers.

Related content: Read our guide to container engines ›

containerd Features

Here are key features of containerd:

• Client—a library you can run on a local or cloud system to integrate containerd into your environment. 
• Namespaces—enable separation between groups of containers on the same host. You can run two containerd containers with the same name in different namespaces. 
• Containers—technically, a container in containerd is a metadata object, and OCI runtimes, container images, and filesystems can be attached to it.
• OCI runtime specification—defines how the container runtime behaves. The OCI specification has functions that generate container specifications based on images.
• Root filesystems—makes it possible to overlay a filesystem on a container or create a snapshot of a filesystem to use in a container. 
• Clone and restore—leverages the criu utility to clone live containers, migrate containers to other machines, and restore containers based on checkpoints.
• Snapshot plugins—enables adding external plugins via GRPC, allowing you to extend snapshot capabilities in containerd.

containerd Security Best Practices

Containers can present a significant security challenge for organizations who are not prepared for complexities of cloud native deployments. As you start using containerd in your organization, you should be aware of security best practices.

It is important to note that containerd has the same attack surface as Docker, out-of-the-box. While containerd does not offer a CLI or SSH interface, anyone with access to the containerd socket file can download crictl, nerdctl, or use curl to talk to the socket and accomplish desired actions (benign, malicious, or otherwise). containerd containers, however, also have Linux capabilities that can be vulnerable to attack, including sys_chroot, audit_write, mknod, and net_raw.

containerd also shares the following attack surfaces with Docker Engine:

• Container images containing vulnerabilities or malicious content
• Hard-coded secrets within images that can be easily obtained by attackers
• Over-privileged containers enabling container escape attacks
• When not orchestrated properly, containers can overuse resources and disrupt other processes
• Vulnerabilities in the underlying operating system kernel

Use these best practices to improve containerd security:

• Never run containers as root and reduce privileges to the minimum necessary.
• Always scan images before using them at all stages of development and deployment.
• Verify image integrity – ensure images are encrypted, signed, and extracted from trusted registries.
• Use the latest secure and verified version of container images.
• Encrypt secrets and use secure secret management mechanisms, which safely inject secrets in production.
• Harden container hosts to prevent attacks such as container breakouts.
• Update containerd, and if it is delivered via a Kubernetes service, use the latest version of the service
• Users should ensure that only authorized users have access to the containerd socket file

Read our guide to container security best practices ›

containerd Security with Aqua

Aqua Security provides container security solutions for modern cloud native ecosystems. Aqua’s solutions for integrated image scanning, Kubernetes security, and container runtime security allow Security and DevOps professionals to establish control points across the application lifecycle and establish end-to-end security coverage. 

To learn more about container security best practices, check out the Container Security Best Practices eBook ›