Open Source Container Tools

The Container Stack: Layers of Abstraction

Understanding the container ecosystem requires knowing how the layers fit together. At the bottom is the Linux kernel, which provides namespaces for process isolation, cgroups for resource limits, and union filesystems for layered storage. These kernel features are what make containers possible, and every container tool ultimately uses them.

Above the kernel sit low-level container runtimes like runc. These programs take a filesystem bundle (the unpacked container image) and a configuration file (specifying namespaces, cgroups, mount points, and security settings), then create and start the container process. runc is the reference implementation of the OCI Runtime Specification, and it is what Docker, Podman, and Kubernetes all use under the hood. Most users never interact with runc directly, but it is the final step in every container launch.

The next layer up includes high-level runtimes like containerd and CRI-O. containerd manages the full container lifecycle: pulling images from registries, unpacking them into filesystem bundles, starting containers via runc, managing container networking, and handling container logs. Docker Engine uses containerd internally, and Kubernetes can use containerd directly through its Container Runtime Interface (CRI). CRI-O is an alternative high-level runtime built specifically for Kubernetes, implementing the CRI without the additional features that Docker includes.

At the top of the stack are the user-facing tools: Docker CLI, Podman, and Kubernetes. These provide the commands and abstractions that developers and operators actually use. Docker CLI talks to the Docker daemon, which talks to containerd, which talks to runc. Podman talks to containerd (or CRI-O) more directly, skipping the daemon layer. Kubernetes talks to containerd or CRI-O through the CRI, managing containers across a cluster rather than on a single host.

Container Build Tools

Building container images is a distinct concern from running them, and several specialized tools handle image construction.

Docker's built-in build system has evolved significantly. BuildKit, which became the default builder in Docker 23.0, supports parallel multi-stage builds, advanced caching with cache mounts, build secrets that are not persisted in the image layers, and output formats beyond Docker images (such as OCI images and local filesystem tarballs). BuildKit can also run as a standalone daemon, independent of Docker, for CI/CD environments that need image building without a full Docker installation.

Buildah is a tool for building OCI container images without requiring a running container daemon. Developed by Red Hat as part of the Podman ecosystem, Buildah can build images from Dockerfiles (using the buildah bud command) or through a scripted approach where you mount a container's filesystem, make changes directly, and commit the result. This scripted approach is useful for complex image builds that are difficult to express in a Dockerfile, such as builds that require mounting host secrets or modifying files in non-linear ways.

Kaniko is a container image builder designed specifically for Kubernetes environments. It builds images inside a standard container without requiring privileged access or a Docker daemon, which makes it safe to run in multi-tenant Kubernetes clusters where privileged containers are not allowed. Kaniko reads a Dockerfile, executes each instruction in userspace, and pushes the resulting image to a registry. It is commonly used as a build step in Tekton pipelines and other Kubernetes-native CI/CD systems.

img, created by Jessie Frazelle, is another unprivileged image builder that uses runc and BuildKit to build images without root access. Buildpacks, standardized through the Cloud Native Buildpacks project, take a different approach entirely by analyzing your application's source code and automatically generating a container image without requiring you to write a Dockerfile at all. Buildpacks detect the language, install dependencies, compile if necessary, and produce an optimized multi-layer image.

Container Registries

Container registries store and distribute container images. Public registries like Docker Hub and GitHub Container Registry host millions of community images, but organizations running production workloads typically need private registries for their proprietary application images.

Harbor is the most feature-rich open source container registry. Originally developed by VMware and now a CNCF graduated project, Harbor provides image storage, role-based access control, image signing and verification with Notary, automated vulnerability scanning with integrated Trivy or Clair, image replication between registries for geo-distribution or disaster recovery, and garbage collection for reclaiming storage from deleted images. Harbor runs on Docker Compose or Kubernetes and supports both Docker and Helm chart repositories.

Quay is Red Hat's open source container registry, available as the self-hosted Project Quay or as the managed Quay.io service. Quay provides vulnerability scanning via Clair, repository mirroring, build triggers from Git repositories, fine-grained access controls, and an audit log of all actions. It integrates particularly well with Red Hat's container toolchain (Podman, Buildah, Skopeo) and OpenShift.

The Docker Distribution project (now called distribution/distribution) provides a lightweight, open source implementation of the OCI Distribution Specification. It is the same code that runs Docker Hub and is suitable for organizations that need a minimal private registry without Harbor's or Quay's additional features. GitLab also includes a built-in container registry in its Community Edition, which is convenient for teams already using GitLab for source control and CI/CD.

Skopeo is a companion tool for working with container registries. It copies images between registries without pulling them to the local machine, inspects image metadata and manifests remotely, and can convert images between different formats (Docker v2, OCI). Skopeo is particularly useful in CI/CD pipelines for promoting images from a staging registry to a production registry without the overhead of a full pull and push cycle.

Container Security and Image Scanning

Container images can contain vulnerabilities in their base operating system packages, application dependencies, or configuration. Scanning images before deployment is a critical step in any secure container workflow.

Trivy, maintained by Aqua Security, is the most popular open source container scanner. It scans container images, filesystem directories, Git repositories, and Kubernetes clusters for vulnerabilities in OS packages and application dependencies (npm, pip, gem, Maven, Go modules, and more). Trivy also checks for infrastructure misconfigurations in Dockerfiles, Kubernetes manifests, Terraform files, and CloudFormation templates. It runs as a single binary with no external dependencies and produces output in multiple formats including JSON, table, and SARIF for integration with CI/CD pipelines and code scanning platforms.

Grype, from the Anchore project, is another fast vulnerability scanner that matches container image contents against vulnerability databases. It pairs with Syft, a tool that generates a Software Bill of Materials (SBOM) from container images, documenting every package and dependency included. SBOMs have become increasingly important for supply chain security and compliance, and tools like Syft and the SPDX standard provide a structured way to produce them.

Clair, originally developed by CoreOS and now maintained by Project Quay, performs static analysis of container images by comparing their contents against known vulnerability databases. Clair is designed to be integrated into container registries (Harbor and Quay both support it) rather than run as a standalone CLI tool, making it suitable for automated scanning at image push time.

Falco, a CNCF graduated project, takes a different approach by monitoring container behavior at runtime rather than scanning images before deployment. Falco uses kernel-level instrumentation (eBPF or a kernel module) to detect unexpected system calls, file access, network connections, and process execution inside running containers. When a container does something outside its expected behavior profile, Falco generates an alert. This runtime security layer catches threats that static image scanning cannot detect, such as zero-day exploits or compromised application logic.

Container Networking and Service Mesh

Container networking is handled by plugins that implement the Container Network Interface (CNI) specification. Calico provides network policy enforcement and BGP-based routing for Kubernetes clusters. Cilium uses eBPF for high-performance networking and observability with fine-grained security policies. Flannel offers a simple overlay network for basic cluster connectivity. Weave Net provides encrypted networking with automatic mesh topology.

Service meshes add observability, traffic management, and security to inter-service communication. Istio is the most comprehensive option, providing mutual TLS encryption, traffic routing and splitting, circuit breaking, retry policies, and distributed tracing for all traffic between services. Linkerd is a lighter alternative that focuses on simplicity and low resource overhead while still providing mTLS, observability, and traffic management. Both are CNCF projects and integrate with any CNI-based Kubernetes network.

Putting the Pieces Together

A secure, production-ready container workflow touches many of these tools. Developers write Dockerfiles and build images using Docker or Buildah. Images are pushed to a private registry like Harbor, which scans them for vulnerabilities using Trivy or Clair. CI/CD pipelines use Kaniko or BuildKit for building in Kubernetes environments. Skopeo promotes images between registries. Kubernetes, with containerd or CRI-O as its runtime, orchestrates the running containers. Falco monitors runtime behavior, and a service mesh handles inter-service communication security.

Not every organization needs every tool in this list. A small team might use Docker for building, Docker Hub or GitLab's built-in registry for storage, and Trivy in their CI pipeline for scanning. A large enterprise might deploy Harbor with integrated Clair, Kaniko for builds, Istio for service mesh, and Falco for runtime monitoring. The open source container ecosystem is modular by design, and each tool can be adopted independently as your needs evolve.