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

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.

The mechanics of storing an artifact in an OCI registry with ORAS follow the OCI Image Specification directly. ORAS packages files as a manifest plus one or more layer blobs; the manifest carries an artifactType field (a media type string) to identify what kind of artifact it is, and a config blob typed as application/vnd.oci.empty.v1+json if no separate config is needed. The content-addressed digest of the manifest is then the artifact’s permanent, immutable identifier — pull it by digest anywhere and you get exactly the bytes pushed. ORAS implements the full OCI Referrers API: when pushing an artifact that annotates an existing image (a signature, an SBOM, a provenance attestation), ORAS sets the manifest’s subject field to the image’s digest, and registries that support referrers index the relationship automatically. An oras discover command then queries that index, showing all artifacts associated with a given image without the caller needing to know their tags or digests in advance. For registries that predate the referrers API, ORAS falls back transparently to the tag-schema fallback defined in the distribution spec.

ORAS ships as three layers of tooling designed for different audiences. The oras CLI is a command-line client for humans and CI pipelines: oras push, oras pull, oras cp (registry-to-registry copy, including transitive referrers), oras discover, and oras manifest fetch. The oras-go library is the Go SDK consumed by projects integrating OCI artifact support into their own tooling — cosign, Notation, and several Kubernetes operators use it directly. Client libraries for .NET, Rust, and Python follow the same core SDK compliance matrix. The practical effect is that the supply chain graph that the OCI Referrers API makes possible — an image with attached signature, SBOM, and attestation, all discovered and verified in a single registry round-trip — is primarily constructed and consumed via ORAS primitives, whether or not the end user ever invokes the oras CLI directly.

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.

SBOM (Software Bill of Materials)

Supply-Chain Security Compliance Containers Oci Standards
A Software Bill of Materials (SBOM) is a structured, machine-readable list of the components that make up a software artifact: open-source libraries, proprietary packages, operating system packages, programming language dependencies, and the transitive dependencies of all of the above. It is the software analogue of the ingredient list on packaged food — the thing that tells a consumer (or an automated system) precisely what is inside. The term and concept predate current security mandates but became a regulatory requirement in the US through Executive Order 14028 (May 2021), which directed NIST and NTIA to define minimum SBOM elements for software sold to the federal government. The NTIA’s resulting guidance specifies seven minimum data fields per component: supplier name, component name, version, component identifier (CPE or PURL), dependency relationships, SBOM author, and timestamp. The practical use cases SBOMs enable are vulnerability management (correlating component versions against CVE databases to identify affected software), licence compliance (detecting GPL or other licence obligations across the dependency graph), and incident response (determining within minutes which systems in a fleet contain a newly-disclosed vulnerable component, as organisations that had SBOMs could do during the Log4Shell response and those without could not).