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 demon process that creates, starts, stops and destroys containers. You can also extract container images from container logs, mount storage, and enable networking for a container.

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

Docker Engine is an example of a high-level container engine

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

fully compliant with the standards set by the Open Container Initiative (OCI), An open government organization focused on container best practices. It also supports the Container Runtime Interface (CRI), a Kubernetes specification developed to allow multiple container runtimes to function as part of a cluster. Kubernetes can use containers and other low-level container runtimes that support OCI to run containers on Kubernetes nodes.

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

In this article:

containerd vs Docker containerd vs CRI vs

OCI vs CRIO vs RUNC

containerd Features of containerd

Security Best Practices
Container security with Aqua
containerd vs

Docker It provides a rich set of technologies used to run and manage containers. One such technology 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 basic container runtime solution. In addition, newer versions of Docker Engine use containers in the background.

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. In the background, 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’s how containerd compares to some 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 the container runtime interface ›
Open Container Initiative (OCI): This is a collaborative effort to maintain a container image specification format. OCI images have a standard format, and can be executed by any container runtime that supports OCI. Therefore, 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 container-like feature sets. CRI-O extracts containers from a registry, manages its lifecycle, and runs a low-level runtime (runc) to run its processes. CRI-O was developed from the beginning as a container runtime for Kubernetes.
runc: This is a low-level runtime that supports OCI. It provides basic functionality, such as interacting with Linux kernel features or managing namespaces and control groups. It does not provide a full CLI or developer utilities. Containerd uses runc to launch containers.

Related content: Read our container engine guide ›

Features of containerd

Here are the key features of

containerd:

Client: A library that you can run on an on-premises system or in the cloud to integrate containerd into your environment.
Namespaces : Enable separation between container groups on the same host. You can run two containers in containers with the same name in different namespaces.
Containers: Technically, a containerized container is a metadata object, and OCI runtimes, container images, and file systems can be attached.

OCI runtime specification

: Defines how the container runtime behaves. The OCI specification has functions that generate image-based container specifications.

Root file systems:

Allows you to overlay a file system on a container or create a snapshot of a file system for use in a container

Clone and Restore: Leverages the criu utility to clone active containers, migrate containers to other machines, and restore checkpoint-based containers.
Plugins snapshots: Allows you to add external plug-ins through GRPC, allowing you to extend the capabilities of containerized snapshots.

Container Security Best Practices

Containers can present a significant security challenge for organizations that are unprepared for the complexities of cloud-native deployments. As you start using containerd in your organization, you should consider security best practices.

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

containerd also shares the following attack surfaces with Docker Engine:

Container images that

contain vulnerabilities or malicious content
Secrets encoded within images that attackers can easily obtain Overprivileged

containers

that allow container escape attacks
When not orchestrated correctly, containers can abuse resources and disrupt other processes
Vulnerabilities in the kernel

the underlying operating system Use these best practices to improve container security:

Never run containers as root and reduce privileges to the minimum necessary

Always scan images before use at all stages of development and deployment.
Verify image integrity: Ensure images are encrypted, signed, and extracted from trusted records.
Use the latest secure and verified version of container images.
Encrypt secrets and use secure secret management mechanisms, which inject secrets securely into production.
Harden container hosts to prevent attacks such as container breaks.

Update in a container

and, if delivered through a Kubernetes service, use the latest version of the service
Users must ensure that only authorized users have access to the containerized socket file

Containerized 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 enable security and DevOps professionals to establish checkpoints throughout the application lifecycle and establish end-to-end security coverage.

For more information on container security best practices, see the Container Security Best Practices eBook ›

Blogs

What is containerd? – Aqua Security