63 Imagine you’re a developer managing applications in a Kubernetes environment. You need object storage to handle growing data demands, but every time a new project requires it, you’re stuck manually requesting and provisioning resources. This not only delays your workflow but also pulls you away from core development tasks. Traditionally, integrating object storage into Kubernetes has been a manual and fragmented process — submitting requests, waiting for approvals, configuring endpoints, and managing access keys. For many, this approach feels outdated in a world that thrives on automation and efficiency.Enter the COSI (Container Object Storage Interface) Driver. Designed to simplify and automate object storage provisioning in Kubernetes, COSI offers a standardized, Kubernetes-native approach. By abstracting the requirements of object storage, COSI enables developers to focus on what truly matters – building and deploying applications – without the constant headache of manual provisioning. Addressing manual Kubernetes provisioning challenges with COSI Scality’s COSI driver directly addresses the challenge of manual, fragmented object storage provisioning in Kubernetes environments. COSI — an emerging standard in Kubernetes — enables dynamic provisioning of buckets in external object storage systems, all controlled through Custom Resource Definitions (CRD) within Kubernetes. This enables developers to create and manage custom objects in Kubernetes just like they would for built-in resources. The result is a true self-service model that automates the entire bucket provisioning process with a declarative configuration. Developers can request resources and have buckets automatically provisioned, all from within Kubernetes to reduce admin and massively simplify their experience. How it works: COSI architecture COSI organizes Kubernetes resources in 3 domains: Admin domain Developers domain COSI subsystem The COSI subsystem functions as the primary COSI controller, managing modifications to COSI API objects. It handles bucket creation, updates, deletion, and access management requests. Each Kubernetes cluster requires one instance of the controller manager, even if multiple object storage providers are used. Understanding the COSI workflow (API) The COSI API is centered around buckets, because the bucket is the unit of abstraction for object storage. COSI defines Kubernetes APIs aimed at managing them. The platform administrator controls the available resources by defining: BucketClass → set of properties to create buckets BucketAccessClass → set of properties of credentials granting access to buckets Developers deploy applications and create: BucketClaim → request for object storage bucket BucketAccess → request for credentials to access the bucket When developers create a BucketClaim this references a BucketClass as a template for creating the resource. When they request BucketAccess this references a BucketAccessClass as a “credential template” and a BucketClaim for the resources to gain access to The COSI subsystem watches all COSI resources and creates: Bucket → a representation of requested bucket with its properties Secret → a Kubernetes resource that will store bucket access information The COSI subsystem uses the Scality COSI driver to interface with the object storage system APIs to: Create the bucket Create an IAM user and access key / secret key pair for that user. It will also create an inline policy to grant access for this user to this particular bucket. Pass these access details to Kubernetes The application pod receives bucket access information and status from Kubernetes resources and directly accesses the bucket via object storage endpoints. COSI driver process workflow. To present this in terms already familiar to a Kubernetes user, Bucket and BucketClaim can be viewed as similar to the PersistentVolume and PersistentVolumeClaim actions from the file/block equivalent StorageClass. Dynamic or static? Matching your workflow COSI is designed to function with both dynamic and static provisioning. Dynamic provisioning allows for the automatic creation of buckets within Kubernetes and for the user that made the request to be able to access them. Static provisioning allows a Kubernetes user to connect to an existing bucket created outside of Kubernetes, this is useful when access to data that already exists is required by the developer. Built for scale: Multi-tenant support COSI is completely multi-tenant enabled, allowing Kubernetes to have access to different IAM accounts on the same Scality RING object storage system or to have access to accounts on different RING storage systems. There is one driver in a Kubernetes cluster, and this driver can talk to different IAM accounts. Tenant isolation in Kubernetes is handled by role-based access control that allows the admin to define Kubernetes actions such as limiting the BucketClass resources requestors can reference when making a claim. Observability included: Metrics, tracing & monitoring The Scality COSI driver provides Open Telemetry-compliant metrics, traces and logs. The driver provides an endpoint where a monitoring system, typically Prometheus, can scrape the metrics. The driver provides metrics about the internal calls, IAM operations, and S3 operation stats, for example the number of buckets and IAM users that are being created and deleted. The driver also supports the enabling of tracing, to trace all the actions within the driver. Developed for developers: Agile, adaptable and evolving As an active contributor to the COSI group of Kubernetes, Scality helps shape the development and evolution of the COSI specification based on real-world customer use cases. Our implementation of the COSI driver is designed to be adaptable and evolve with the needs of our users. The driver’s architecture allows for independent release cycles, meaning we can deploy new features and bug fixes without waiting for major RING releases. This agile approach allows us to stay aligned with the evolving COSI standard while responding rapidly to customer requirements, ensuring the driver continues to deliver meaningful value as use cases grow and change. Why it matters: Key benefits of Scality’s COSI Driver at a glance Simplified workflows: Developers can create and manage buckets directly from Kubernetes, eliminating the need for manual requests and lengthy wait times. Automation: The driver automates bucket provisioning and user management, reducing administrative overhead and accelerating development cycles. Multi-tenancy: Our driver supports multi-tenancy, allowing one Kubernetes cluster to access multiple accounts and rings, providing flexibility and scalability. Standard compliance: Built on standard S3 and IAM interfaces, our driver works seamlessly with RING, ARTESCA, and any system that speaks standard S3 and IAM (with support available for RING and shortly ARTESCA). Metrics and tracing: The driver includes open telemetry-compliant metrics and tracing, enabling robust monitoring and troubleshooting. Looking ahead and driving innovation, one bucket at a time We believe Scality’s COSI driver can fundamentally improve how developers interact with object storage in Kubernetes. By delivering a seamless, automated, developer-friendly experience, we’re helping teams reduce operational friction and focus on what matters most—building and deploying great applications. To dive deeper, visit our GitHub page for detailed documentation, installation guides, and everything you need to get started with the COSI driver. At Scality, we’re not just delivering storage—we’re building tools that give our customers freedom to innovate. The COSI driver is just one way we’re putting developer needs and customer-centric design at the core of everything we do
