Authorization - v1.x

Starting with CSM 1.13, Authorization v1.x will be deprecated and will be officially discontinued by CSM 1.15 in September 2025. Please switch to Authorization v2.0 before then to avoid any issues. Migration steps are available here.

The following diagram shows a high-level overview of Container Storage Module for Authorization with a tenant-app that is using a CSI driver to perform storage operations through the Authorization proxy-server to access the a Dell storage system. All requests from the CSI driver will contain the token for the given tenant that was granted by the Storage Administrator.

Container Storage Module for Authorization

Container Storage Module Authorization Capabilities

Feature PowerFlex PowerMax PowerScale Unity XT PowerStore
Ability to set storage quota limits to ensure k8s tenants are not over consuming storage Yes Yes No (natively supported) No No
Ability to create access control policies to ensure k8s tenant clusters are not accessing storage that does not belong to them Yes Yes No (natively supported) No No
Ability to shield storage credentials from Kubernetes administrators ensuring credentials are only handled by storage admins Yes Yes Yes No No

NOTE: PowerScale OneFS implements its own form of Role-Based Access Control (RBAC). Authorization does not enforce any role-based restrictions for PowerScale. To configure RBAC for PowerScale, refer to the PowerScale OneFS documentation.

Authorization Components Support Matrix

Authorization consists of 2 components - The authorization sidecar, bundled with the driver, communicates with the Authorization proxy server to validate access to Storage platforms. The authorization sidecar is backward compatible with older Authorization proxy server versions. However, it is highly recommended to have the Authorization proxy server and sidecar installed from the same release of Container Storage Module.

NOTE: If the deployed CSI driver has a number of controller pods equal to the number of schedule nodes in your cluster, Authorization may not be able to inject properly into the driver’s controller pod. To resolve this, please refer to our troubleshooting guide on the topic.

Roles and Responsibilities

The Container Storage Module for Authorization CLI can be executed in the context of the following roles:

  • Storage Administrators
  • Kubernetes Tenant Administrators

Storage Administrators

Storage Administrators can perform the following operations within Container Storage Module for Authorization

  • Tenant Management (create, get, list, delete, bind roles, unbind roles)
  • Token Management (generate, revoke)
  • Storage System Management (create, get, list, update, delete)
  • Storage Access Roles Management (assign to a storage system with an optional quota)

Tenant Administrators

Tenants of Container Storage Module for Authorization can use the token provided by the Storage Administrators in their storage requests.

Workflow

  1. Tenant Admin requests storage from a Storage Admin.
  2. Storage Admin uses Container Storage Module Authorization CLI to:
    a) Create a tenant resource.
    b) Create a role permitting desired storage access.
    c) Assign the role to the tenant and generate a token.
  3. Storage Admin returns a token to the Tenant Admin.
  4. Tenant Admin inputs the Token into their Kubernetes cluster as a Secret.
  5. Tenant Admin updates CSI driver with Container Storage Module Authorization sidecar module.

Container Storage Module for Authorization Workflow