Kubernetes COSI: Simplifying Object Storage with VAST Data

When Kubernetes was first designed, it came with strong support for compute and block storage through the Container Storage Interface (CSI). CSI standardized how workloads could consume persistent volumes, enabling automation, portability, and ecosystem growth. But object storage—one of the most critical storage paradigms for modern applications—was left behind.

That gap led to the creation of the Container Object Storage Interface (COSI), an emerging Kubernetes standard that allows applications to dynamically request, provision, and consume object storage buckets in the same way that CSI enables block storage volumes.

In this post, we’ll explore why COSI exists, what problems it solves compared to “just provisioning object storage manually,” and how VAST Data integrates with and extends COSI to deliver enterprise-grade capabilities.

---

Why COSI Exists

At first glance, object storage might seem simpler than block or file storage. A bucket is just a logical container—you can create one with a single aws s3 mb command or a line of YAML through your object storage system’s API. Why do we need an entire Kubernetes API around this?

The answer lies in scale, repeatability, and automation.

• Manual provisioning doesn’t scale: In traditional environments, administrators pre-create buckets, hand out access keys, and manually wire credentials into workloads. This model quickly becomes unmanageable when dealing with hundreds or thousands of microservices.
• Dynamic provisioning is critical: Developers want to define their object storage needs in their deployment YAML. Just like a PersistentVolumeClaim for block storage, a BucketClaim in COSI lets them request storage resources without needing to talk to a storage admin.
• Consistent lifecycle management: Buckets, access policies, and credentials should follow the lifecycle of the Kubernetes resource. When the app is deleted, the bucket (or its credentials) can be reclaimed or cleaned up automatically.
• Portability and standardization: COSI provides a common API that works across different object storage backends, eliminating the need for cluster operators to re-architect automation when switching vendors.

In short, COSI brings self-service, automation, and policy-driven lifecycle management to object storage in Kubernetes.

---

How COSI Works

COSI introduces three key Kubernetes resources:

1. BucketClass – Defines storage classes for object storage (e.g., standard vs archive tier, data protection settings).
2. BucketClaim – A request for a bucket by an application.
3. BucketAccess – Manages credentials and access permissions.

Behind the scenes, a COSI driver runs in the cluster and interfaces with the object storage backend. It provisions buckets, generates access keys, and enforces policies defined in the BucketClass.

For developers, this means a simple YAML declaration:

apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClaim
metadata:
  name: my-app-bucket
spec:
  bucketClassName: standard

The cluster handles the rest—provisioning the bucket on the backend, wiring access credentials into the pod, and ensuring lifecycle consistency.

---

VAST Data and Kubernetes COSI

VAST Data extends COSI with the unique benefits of its universal storage platform, enabling Kubernetes workloads to consume object storage with enterprise-grade guarantees:

1. Unified Storage Engine: With VAST, COSI buckets live on the same platform that powers block, file, and database services. This simplifies operations and reduces silos while still supporting S3-compatible access.
2. Performance at Scale: Unlike traditional object stores optimized for capacity but not speed, VAST delivers low-latency and high-throughput S3 performance—critical for modern data-intensive Kubernetes workloads like AI/ML pipelines, analytics, and media processing.
3. Policy-Driven BucketClasses: VAST lets administrators expose bucket classes tied to real backend policies—data protection (erasure coding, snapshots), security (encryption, immutability), and tiering—so Kubernetes developers consume object storage aligned with enterprise governance.
4. Lifecycle Automation: Buckets and credentials created via COSI on VAST can be tied to namespace or workload lifecycles, ensuring compliance and reducing orphaned resources.
5. Deep Integration with VAST Ecosystem: By using VAST’s COSI driver, Kubernetes clusters benefit from the same consistency, scale, and global namespace that VAST provides across object, file, and block.

---

Why It Matters

The promise of Kubernetes has always been about self-service, automation, and portability. COSI brings that promise to object storage, enabling developers to request and consume buckets without manual intervention.

For organizations standardizing on VAST Data, this means:

• Faster developer velocity – No tickets, no manual bucket provisioning.
• Reduced operational overhead – Policies and automation handle lifecycle.
• Enterprise-grade data services – All powered by VAST’s universal storage engine.

COSI is not just about buckets—it’s about unlocking cloud-native agility for data-driven applications. With VAST Data’s support, enterprises can extend these capabilities to mission-critical workloads at petabyte scale.

---

Sample Kubernetes YAML Workflow with VAST’s COSI Driver

1. Install the VAST COSI Driver

First, you’d install the necessary Custom Resource Definitions (CRDs) and controller into your cluster as outlined in VAST’s documentation  .

2. Create a Kubernetes Secret

You’ll need a Kubernetes secret containing credentials or a VMS authentication token for the VAST COSI driver to authenticate with your VAST cluster:

apiVersion: v1
kind: Secret
metadata:
  name: vast-cosi-auth
  namespace: vast-cosi-system
type: Opaque
stringData:
  # either:
  # - Vast Access Key and Secret Key
  # - or an authentication token from VMS (preferred for VAST Cluster 5.3+)
  access_key: "<YOUR_VAST_ACCESS_KEY>"
  secret_key: "<YOUR_VAST_SECRET_KEY>"
  # OR for token-based auth (VAST 5.3+):
  # token: "<YOUR_VAST_VMS_AUTH_TOKEN>"

Documentation notes that from VAST Cluster version 5.3 or later, authentication using VMS authentication tokens is supported  . This is the preferred method over static credentials.

3. Define a BucketClass

Define how buckets should be provisioned—e.g., performance, data protection, or snapshot policies:

apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClass
metadata:
  name: vast-standard
spec:
  # backend-specific class name that maps to a policy on the VAST platform
  provisioner: vast.cosi.vastdata.com
  parameters:
    # The “policy” should correspond to configured policies in VAST (e.g., erasure coding, snapshot-enabled)
    policy: standard-performance-s3

This ties Kubernetes bucket requests to VAST backend policies for performance, protection, and lifecycle management.

4. Create a BucketClaim

Applications can request a bucket just like a PersistentVolumeClaim:

apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClaim
metadata:
  name: myapp-data-bucket
spec:
  bucketClassName: vast-standard
  # optional: request a specific bucket name or let VAST assign one
  # bucketName: myapp-data-123

The COSI controller will then provision an S3 bucket on the VAST platform according to the defined BucketClass.

5. Access Credentials with BucketAccess

To get credentials and endpoint information for your newly provisioned bucket:

apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketAccess
metadata:
  name: myapp-data-access
spec:
  bucketClaimName: myapp-data-bucket

This resource enables Kubernetes (and your workloads) to retrieve credentials and other relevant metadata automatically.

6. Use in a Pod or Deployment

You can now mount or inject access credentials via Kubernetes secrets generated by the COSI controller. They may look like this in a pod:

apiVersion: v1
kind: Pod
metadata:
  name: app-using-object-storage
spec:
  containers:
    - name: app
      image: your-app-image:latest
      env:
        - name: AWS_ACCESS_KEY_ID
          valueFrom:
            secretKeyRef:
              name: myapp-data-access
              key: accessKeyID
        - name: AWS_SECRET_ACCESS_KEY
          valueFrom:
            secretKeyRef:
              name: myapp-data-access
              key: secretAccessKey
        - name: S3_ENDPOINT
          valueFrom:
            secretKeyRef:
              name: myapp-data-access
              key: endpoint

Your application now consumes S3-compatible object storage provisioned via VAST, fully automated via Kubernetes.

---

How This Reflects VAST’s COSI Capabilities

• Dynamic Provisioning: The spec-driven bucket creation (via BucketClaim) automates request handling, bucket creation, and credentials—all without manual intervention  .
• Modern Authentication: Support for VMS token-based authentication (available in VAST Cluster 5.3+) enhances security and reduces the need for static credentials  .
• Tight Integration with VAST Policies: The BucketClass maps directly to backend policy configurations in VAST—e.g., snapshot-enabled classes, performance tiers, etc.—so storage behavior is precisely controlled  .

---

Summary

With this YAML workflow, developers can request object storage through Kubernetes, and the VAST COSI driver will handle provisioning, access control, and lifecycle—all aligned with enterprise-grade policies and authentication strategies.

Let me know if you’d like to include a full end-to-end blog outline or further illustrations—like diagramming this workflow, best practices on bucket naming, cleanup strategies, or operational guidance!

see a demo all it all looks, below

please always use the official documentation as things may change

https://support.vastdata.com/s/document-item?bundleId=vast-cosi-driver-2.6-administrator-s-guide&topicId=about-vast-cosi-driver.html&_LANG=enus