Understanding COSI: Kubernetes’ Standard for Object Storage Management

This article introduces the Container Object Storage Interface (COSI), a standard for provisioning and using object storage in Kubernetes. It is an alpha feature in Kubernetes v1.25.

File and block storage are first‑class citizens in the Kubernetes ecosystem via the Container Storage Interface (CSI). Workloads using CSI volumes enjoy portability across vendors and clusters without changing application manifests. Object storage lacks an equivalent standard.

In recent years, object storage has become increasingly popular as an alternative to file systems and block devices. The object storage paradigm promotes the separation of compute and storage, delivering data over the network rather than locally. This decoupled architecture enables stateless compute workloads that are easier to manage, scale, and automate.

COSI

COSI aims to standardize object storage usage and provides the following benefits:

Kubernetes Native: configure, provision, and manage buckets using the Kubernetes API.

Self‑Service: clear separation between management and operations, enabling DevOps self‑service capabilities.

Portability: achieve vendor neutrality through portability across Kubernetes clusters and object‑storage providers.

Cross‑vendor portability is possible only when both vendors support a common data‑path API, such as the S3 API. For example, buckets can be migrated between AWS S3 and Ceph or MinIO, but not between AWS S3 and Google Cloud GCS.

Architecture

COSI consists of three components:

COSI Controller Manager

COSI Sidecar

COSI Driver

The COSI Controller Manager acts as the primary controller handling changes to COSI API objects, processing bucket creation, updates, deletions, and access‑management requests. One instance is required per Kubernetes cluster, regardless of the number of object‑storage providers.

The COSI Sidecar serves as a translator between COSI API requests and vendor‑specific COSI drivers, using a standardized gRPC protocol that drivers must implement.

The COSI Driver is the vendor‑specific component that receives requests from the sidecar and invokes the appropriate provider API to create buckets, manage their lifecycle, and control access.

API

COSI’s API is bucket‑centric, defining three primary Kubernetes resources to manage buckets:

Bucket

BucketClass

BucketClaim

Two additional resources manage bucket access and authentication:

BucketAccess

BucketAccessClass

In short, a Bucket and BucketClaim are analogous to PersistentVolume and PersistentVolumeClaim, while BucketClass corresponds to StorageClass in the file/block world.

Because object storage is always accessed over the network, credentials are required. BucketAccess and BucketAccessClass represent those credentials and authentication policies. More details are available in the official COSI proposal:

https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1979-object-storage-support

Self‑Service

Beyond providing Kubernetes‑API‑driven bucket management, COSI enables DevOps engineers to configure and manage buckets without administrator intervention, accelerating development cycles and time‑to‑market.

COSI achieves this by dividing bucket configuration steps between two stakeholders: an administrator and a cluster operator. Administrators define broad policies and limits for bucket configuration and access, while operators can freely create and use buckets within those constraints.

For example, an operator may be limited to a maximum provisioned capacity of 100 GB, yet still create buckets for developers within that quota. Administrators can also restrict which users may access specific buckets.

Portability

The third goal of COSI is vendor‑neutral bucket management. COSI supports two types of portability:

Cross‑Cluster

Cross‑Provider

Cross‑cluster portability allows a bucket configured in one cluster to be usable in another, provided the underlying object‑storage backend is reachable from both clusters.

Cross‑provider portability enables organizations to migrate seamlessly from one object‑storage provider to another without changing application definitions (PodTemplates, StatefulSets, Deployments, etc.), assuming both providers expose the same data‑path API.

COSI does not handle data migration itself; additional mechanisms are required if data must be moved between providers.

Next Steps

The vibrant sig‑storage‑cosi community is working to bring the COSI standard to alpha status, and many vendors are expected to contribute compatible drivers.

Future work includes adding more authentication mechanisms, designing advanced bucket‑sharing primitives, multi‑cluster bucket management, and other innovative ideas.