11. Multi-Tenant CSI Deployment Models

New
  • Updated on May 1, 2026
  • Published on May 1, 2026
  • 4 minute(s) read
Prev Next

This section describes two deployment models for integrating VAST CSI in multi-tenant environments:

  1. CSI in Tenant VPC

  2. CSI at CSP Network

These models differ primarily in where the Kubernetes and CSI control plane runs, and how tenant isolation is enforced across identity, storage, and networking.

Reference documents:

  • VAST CSI Documents: About VAST CSI Driver

  • Steps to deploy VAST CSI: Steps to Deploy VAST CSI Driver  

    • Configure the VAST cluster.

    • Create a Kubernetes secret with VMS user credentials or API token for VAST CSI Driver.

    • Add the Helm repository that contains the VAST CSI Driver chart.

    • Create a Helm chart configuration file for VAST CSI Driver.

    • Install the Helm chart for VAST CSI Driver.

CSI in Tenant VPC

In this model, each tenant operates its own Kubernetes environment, and the VAST CSI driver runs within that same boundary. Storage provisioning, authentication, and data access are executed using tenant-scoped identity and configuration.

Because the control plane and data plane are aligned within the same tenant boundary, isolation is inherent rather than enforced.

Tenant-A VPC

This is the simplest model for multi-tenant CSI deployments because the tenant boundary is enforced by the environment itself. The Kubernetes cluster, CSI driver, secrets, and networking all belong to the same tenant, and the VAST backend is accessed using a tenant-scoped identity.

The CSI driver is configured with tenant-specific parameters such as vipPool (or FQDN), storagePath, viewPolicy, and secretName. These parameters define both how volumes are created and how they are accessed.

All PVCs are provisioned under a tenant-owned root such as /k8s/tenant-a, ensuring a clear backend namespace boundary and minimizing the risk of cross-tenant access.

Authentication

The recommended authentication method for the VAST CSI driver is username/password-based authentication, optionally scoped to a tenant.

Tenant-scoped authentication is achieved by including the tenant name in the Kubernetes secret, allowing the CSI driver to operate within a specific tenant context using tenant admin credentials.

apiVersion: v1
kind: Secret
metadata:
  name: vast-tenant-a
  namespace: tenant-a
type: Opaque
stringData:
  username: "tenant-a-admin"
  password: "********"
  tenant: "tenant-a"

Each tenant uses its own credentials, ensuring that CSI operations are executed strictly within the correct tenant scope.

The tenant field defines the VAST tenant context for all CSI operations. All API calls (volume create/delete/list) are executed within this tenant, and all storagePath values are resolved relative to that tenant.

  • One customer cluster or one clearly isolated customer Kubernetes environment

  • One VAST tenant-scoped secret

  • One or more customer-only StorageClasses

  • One customer-only storage path root (e.g. /k8s/tenant-a)

  • One customer-facing VIP pool or FQDN

  • Optional multiple classes for service tiers such as default, high-performance, read-only, etc.

Default / General Purpose

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: tenant-a-default
provisioner: csi.vastdata.com
parameters:
  vipPool: "tenant-a-vip-pool"
  secretName: "vast-tenant-a"
  secretNamespace: "tenant-a"
  storagePath: "/k8s/tenant-a"
  viewPolicy: "tenant-a-default"
volumeBindingMode: Immediate

High Performance Tier

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: tenant-a-default
provisioner: csi.vastdata.com
parameters:
  vipPool: "tenant-a-vip-pool"
  secretName: "vast-tenant-a"
  secretNamespace: "tenant-a"
  storagePath: "/k8s/tenant-a-perf"
  viewPolicy: "tenant-a-high-perf"
volumeBindingMode: Immediate

Read-Only Dataset

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: tenant-a-default
provisioner: csi.vastdata.com
parameters:
  vipPool: "tenant-a-vip-pool"
  secretName: "vast-tenant-a"
  secretNamespace: "tenant-a"
  storagePath: "/datasets/common"
  viewPolicy: "read-only-policy"
volumeBindingMode: Immediate

Note: Read-only behavior is enforced by the VAST viewPolicy, not by Kubernetes access modes alone.

CSI at CSP Network

In this model, CSI and Kubernetes run in the CSP network rather than the tenant VPC and the CSP operates the Kubernetes cluster and CSI driver. Tenants consume the platform as a managed service.

This can be implemented either as a dedicated Kubernetes cluster per tenant or as a shared Kubernetes cluster for multiple tenants.

Tenant-A VPC and Tenant-B VPC

In this model, the Kubernetes control plane and CSI driver are operated by the CSP. Tenants are onboarded into this environment and consume storage through controlled interfaces.

Because the control plane is outside the tenant boundary, isolation must be enforced explicitly across Kubernetes, identity, backend configuration, and networking. Storage is exposed through CSP-defined StorageClasses, which act as a service catalog. Tenants consume these classes but do not define them.

Dedicated Cluster per Tenant

Each tenant has its own Kubernetes cluster within the CSP network. In this case, StorageClasses are naturally tenant-isolated because no other tenants share the cluster.

Shared Cluster for Multiple Tenants

Multiple tenants share a single Kubernetes cluster and CSI driver. In this case, isolation must be explicitly enforced.

Authentication

Each tenant is assigned a dedicated Kubernetes secret containing username/password credentials and the tenant name. In this model, the CSI driver uses multiple secrets, one per tenant.

apiVersion: v1
kind: Secret
metadata:
  name: vast-tenant-a
  namespace: tenant-a
type: Opaque
stringData:
  username: "tenant-a-admin"
  password: "********"
  tenant: "tenant-a"
apiVersion: v1
kind: Secret
metadata:
  name: vast-tenant-b
  namespace: tenant-b
type: Opaque
stringData:
  username: "tenant-b-admin"
  password: "********"
  tenant: "tenant-b"

When a PVC is created:

  1. The StorageClass determines which secretName is used

  2. The CSI driver retrieves that secret

  3. The driver authenticates to VAST using the credentials

  4. The tenant field selects the correct tenant context

This allows a single CSI driver to safely operate across multiple tenants:

  • CSI → secret A → Tenant A

  • CSI → secret B → Tenant B

Note: Each request is isolated as long as secrets, StorageClasses, and storage paths are not shared across tenants.

Example StorageClass Design (Shared Cluster)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: tenant-a-standard
provisioner: csi.vastdata.com
parameters:
  vipPool: "tenant-a-vip-pool"
  secretName: "vast-tenant-a"
  secretNamespace: "vast-system"
  storagePath: "/k8s/tenant-a"
  viewPolicy: "tenant-a-standard"
volumeBindingMode: Immediate

Note: In shared clusters, each tenant must have its own StorageClasses referencing its own secret, storage path, and VIP pool.

Read-Only Dataset Class

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: tenant-a-dataset-ro
provisioner: csi.vastdata.com
parameters:
  vipPool: "tenant-a-vip-pool"
  secretName: "vast-tenant-a"
  secretNamespace: "vast-system"
  storagePath: "/datasets/common"
  viewPolicy: "read-only-policy"
volumeBindingMode: Immediate

  • One or more CSP-managed Kubernetes clusters

  • Per-tenant namespaces or clusters (depending on deployment model)

  • One VAST tenant-scoped secret per tenant

  • A controlled catalog of StorageClasses defined by the CSP

  • Per-tenant storage paths (e.g. /k8s/tenant-a, /k8s/tenant-b)

  • Per-tenant VIP pools or controlled network isolation

  • Optional service tiers (standard, performance, read-only datasets, etc.)

Note: Tenants do not define storage behavior - they consume CSP-defined storage services

Related articles