Concepts on Open Component Model

Component Identity

Mon, 01 Jan 0001 00:00:00 +0000

Overview

OCM uses a coordinate system to uniquely identify every piece of software — from entire components down to individual artifacts. This page explains how that system works, what a component descriptor contains, and how identity stays stable regardless of where artifacts are stored.

Transfer and Transport

Mon, 01 Jan 0001 00:00:00 +0000

Transfer is the mechanism that moves component versions from one OCM repository to another. During transfer, the component’s identity, integrity, and signatures are preserved so that consumers can verify provenance at every stage of the delivery pipeline.

Signing and Verification

Mon, 01 Jan 0001 00:00:00 +0000

OCM uses cryptographic signatures to guarantee that component versions are authentic (created by a trusted party) and have not been tampered with during storage or transfer.

Credential System

Mon, 01 Jan 0001 00:00:00 +0000

OCM operations frequently interact with protected services — OCI registries, private repositories, signing infrastructure. Rather than requiring credentials at every command invocation, OCM provides a central credential system that decouples what needs authentication from how credentials are supplied.

Resolvers

Mon, 01 Jan 0001 00:00:00 +0000

Why Resolvers?

In OCM, a component can reference other components. For example, an app component might reference a backend and a frontend component. These referenced components don’t have to live in the same repository as the app — and in practice, they often don’t. Teams publish components independently, to different registries or repository paths.

Resource Repositories

Mon, 01 Jan 0001 00:00:00 +0000

A component version describes a set of resources (container images, Helm charts, configuration files) but it does not necessarily store those resources itself. Resource repositories are the abstraction OCM uses to upload, download, and authenticate against the actual storage backends where resource artifacts live.

Canonical Component Repositories

Mon, 01 Jan 0001 00:00:00 +0000

What Are Canonical Component Repositories?

A canonical repository is a repository that contains all components of a component graph: the root component and every component it references, directly or transitively.

Kubernetes Controllers

Mon, 01 Jan 0001 00:00:00 +0000

The OCM controllers reconcile OCM component versions into a Kubernetes cluster. They form a chain of four custom resources, each depending on the previous one becoming Ready:

Kubernetes Deployer

Mon, 01 Jan 0001 00:00:00 +0000

The Deployer is a Kubernetes controller that takes an OCM resource, typically containing Kubernetes manifests such as a ResourceGraphDefinition, plain YAML, or other deployable content, downloads it from a Resource, and applies it to the cluster using server-side apply.

Plugin System

Mon, 01 Jan 0001 00:00:00 +0000

The Open Component Model (OCM) plugin system allows you to extend OCM’s basic capabilities. Plugins add support for new repository types, credential providers, signing mechanisms, input formats, and more, without modifying OCM itself.

Ownership

Mon, 01 Jan 0001 00:00:00 +0000

Ownership is about tracing a resource back to its owning component version. Find a resource in a registry and it looks like any other image: nothing on it points back to the component version it belongs to. The component version lists its resources, but the resources carry no information about the component version.

Software Bills of Materials

Mon, 01 Jan 0001 00:00:00 +0000

A Software Bill of Materials is an inventory of what is inside an artifact: packages, libraries and versions. It is what a scanner reads to show what CVEs might affect the current items. To read a full description, please read the National Telecommunications and Information Administration’s SBOM Page.