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.

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.