↓ Skip to main content
Le Site de François
  1. Index/

OCI (Open Container Initiative)

Containers Standards Runtime Registry Linux-Foundation

The Open Container Initiative (OCI) is a Linux Foundation project founded in June 2015 by Docker, CoreOS, and others to prevent the container ecosystem from fragmenting around proprietary formats. It maintains three interlocking specifications that together describe the complete lifecycle of a container: how an image is structured, how it is transported, and how it is run. Any tool that conforms to these specs — builder, registry, runtime — is interoperable with any other conformant tool, which is why an image built by buildah can be pushed to a registry running Harbor, pulled by containerd, and executed by a runtime written in Rust.

The Image Specification defines the on-disk and on-wire format of a container image. An image is a Merkle DAG of content-addressed blobs: a manifest (a JSON document listing the image’s layers and config by their SHA-256 digests), a config blob (containing runtime defaults like entrypoint, environment variables, and architecture), and one or more layer blobs (filesystem changesets stored as tarballs, optionally compressed with gzip or zstd). Every component is addressed by its digest, so the manifest’s own digest serves as an immutable, content-addressable identifier for the entire image — the same digest always refers to exactly the same content, everywhere. Image v1.1 (2024) extended the format with artifacts: arbitrary blobs — SBOMs, signatures, attestations, Helm charts — can be stored in the same registry using the same manifest structure, with a subject field pointing at the image they annotate, and a referrers API in the distribution spec for querying them.

The Runtime Specification defines what happens when an OCI image is unpacked into a filesystem bundle and handed to a runtime. It specifies the config.json format that describes the container’s root filesystem, namespaces, cgroups, capabilities, mounts, and seccomp/apparmor profiles. runc is the OCI reference runtime implementation, donated by Docker at OCI’s founding, and remains the low-level execution engine underneath containerd and CRI-O on most Kubernetes nodes. The Distribution Specification standardises the HTTP API that registries expose for pushing and pulling content — the v2 registry API originally developed by Docker — ensuring that any OCI-conformant client can speak to any OCI-conformant registry. Together the three specs form the substrate on which the entire cloud-native container ecosystem — Kubernetes, CoCo, composefs image layer deduplication, and image-based Linux delivery via bootc — is built.

Related

OCI Referrers API

Containers Oci Supply-Chain Registry Security Standards
OCI Referrers is a mechanism introduced in the OCI Image and Distribution Specification v1.1 (finalised 2024) that allows arbitrary artifacts — signatures, SBOMs, vulnerability scan reports, attestations, provenance documents — to be attached to an existing image in a registry without modifying the image itself and without requiring out-of-band storage or tag conventions. The attachment is expressed through a subject field added to any OCI manifest: a descriptor pointing to the digest of the target image. The registry then indexes these relationships, and the referrers API makes them discoverable.

Kata Containers

Containers Security Virtualization Kubernetes Cncf Oci Runtime
Kata Containers is an Open Infrastructure Foundation (OpenInfra Foundation) project that replaces the Linux namespace and cgroup isolation of a conventional container runtime with a full VM boundary, while remaining entirely compatible with the OCI runtime specification and the Kubernetes CRI. From the perspective of containerd, CRI-O, or the Kubernetes kubelet, a Kata pod is indistinguishable from a runc or crun pod — the same API calls, the same lifecycle verbs, the same pod spec — but instead of calling clone() to create a new namespace, Kata starts a lightweight virtual machine. The workload runs inside that VM with its own kernel, its own device model, and a hardware-enforced isolation boundary between itself and the host kernel. The premise is that Linux namespaces, while convenient, share the same kernel as the host: a kernel vulnerability exploitable from inside a container can affect the host and every other container running on the same node. A VM boundary means that even a full guest kernel compromise cannot directly affect the host.

ORAS (OCI Registry As Storage)

Containers Oci Supply-Chain Registry Cncf Artifacts
ORAS (OCI Registry As Storage) is a CNCF project that treats an OCI-conformant registry not as a container image store but as a general-purpose content-addressable storage system for any kind of artifact. Its central insight is that the OCI Distribution and Image specifications are already a well-understood, widely-deployed, access-controlled, geo-replicated, content-addressed storage substrate — and that the ecosystem does not need a separate storage solution for every new artifact type (Helm charts, WebAssembly modules, ML models, firmware images, OPA policies, SBOMs, attestations) when the same registry infrastructure can store all of them, using the same authentication, the same tooling, and the same pull-by-digest semantics that container images already use.