Starting with CSM 1.12, all deployments will need to use images from quay.io. Please note that from CSM 1.14 (May 2025), upgrading with helm will fail if it attempts to use images from Docker Hub.
This section outlines the upgrade steps for Container Storage Modules (CSM) for Authorization. The upgrade of CSM for Authorization is handled in 2 parts:
Helm Chart Upgrade
Upgrading the Dell CSI drivers with CSM for Authorization enabled
Starting with CSM 1.15, CSM Authorization (v2.3.0) requires users to configure storage credentials prior to deployment. This is a mandatory step to ensure proper access to external storage systems.
You can configure storage credentials using one of the following methods:
Dynamic Secrets via SecretProviderClass
Use this method if you are integrating with external secret management systems (e.g., HashiCorp Vault, CyberArk Conjur) through the Secrets Store CSI Driver.
Static Credentials via Kubernetes Secret
Use this method if you prefer to manually manage credentials within Kubernetes.
Note: Only one of SecretProviderClass or Secret can be used at a time.
Note: If you are using Conjur with the Secrets Store CSI Driver, be sure to configure --set 'tokenRequests[0].audience=conjur' when installing the Secrets Store CSI Driver.
Create your own SecretProviderClass Object based on your external secret provider. You also have the option to create your own Redis secret in the SecretProviderClass.
Minimal SecretProviderClass configuration: includes only array-based credentials
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: vault-db-creds
spec:
# Vault CSI Provider provider: vault
parameters:
# Vault role name to use during login roleName: 'csm-authorization'# Vault's hostname vaultAddress: 'https://vault:8200'# TLS CA certification for validation vaultCACertPath: '/vault/tls/ca.crt' objects: | - objectName: "dbUsername" secretPath: "database/creds/db-app" secretKey: "username" - objectName: "dbPassword" secretPath: "database/creds/db-app" secretKey: "password"# "objectName" is an alias used within the SecretProviderClass to reference# that specific secret. This will also be the filename containing the secret.# "secretPath" is the path in Vault where the secret should be retrieved.# "secretKey" is the key within the Vault secret response to extract a value from.
SecretProviderClass configuration with array-based and Redis credentials
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: vault-db-creds
spec:
# Vault CSI Provider provider: vault
secretObjects:
# Name of the Kubernetes Secret object# This name will be used during deployment - secretName: redis-secret-vault
type: kubernetes.io/basic-auth
data:
# Name of the mounted content to sync# This could be the object name or the object alias - objectName: dbRedisUsername
# Data field to populate key: username
- objectName: dbRedisPassword
key: password
parameters:
# Vault role name to use during login roleName: 'csm-authorization'# Vault's hostname vaultAddress: 'https://vault:8200'# TLS CA certification for validation vaultCACertPath: '/vault/tls/ca.crt' objects: | - objectName: "dbUsername" secretPath: "database/creds/db-app" secretKey: "username" - objectName: "dbPassword" secretPath: "database/creds/db-app" secretKey: "password" - objectName: "dbRedisUsername" secretPath: "database/creds/redis" secretKey: "username" - objectName: "dbRedisPassword" secretPath: "database/creds/redis" secretKey: "password"# "objectName" is an alias used within the SecretProviderClass to reference# that specific secret. This will also be the filename containing the secret.# "secretPath" is the path in Vault where the secret should be retrieved.# "secretKey" is the key within the Vault secret response to extract a value from.
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: conjur-db-creds
spec:
provider: conjur
secretObjects:
# Name of the Kubernetes Secret object# This name will be used during deployment - secretName: redis-secret-conjur
type: kubernetes.io/basic-auth
data:
# Name of the mounted content to sync# This could be the object name or the object alias - objectName: secrets/redis-username
# Data field to populate key: username
- objectName: secrets/redis-password
key: password
parameters:
conjur.org/configurationVersion: 0.2.0
account: replace-me-account
applianceUrl: 'https://conjur-conjur-oss.default.svc.cluster.local' authnId: authn-jwt/kube
sslCertificate: | -----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
Create a YAML file (in this example, storage-secret.yaml) containing the credentials:
# Username and password for accessing storage systemusername: "username"password: "password"
To upgrade an existing Helm installation of CSM for Authorization to the latest release, download the latest Helm charts.
helm repo update
Check if the latest Helm chart version is available:
helm search repo dell
NAME CHART VERSION APP VERSION DESCRIPTION
dell/csm-authorization 2.3.0 2.3.0 CSM for Authorization is part of the [Container...
Ensure your myvalues.yaml file is updated to align with the latest configuration changes—this includes adding new parameters, removing deprecated ones, and adjusting any modified values introduced in the upgrade.
Upgrade to the latest CSM for Authorization release:
Update your Storage, Role, and Tenant resource definitions with the latest configuration schema. Apply changes using the Kubernetes CLI:
kubectl apply -f <file-name> -n authorization
Upgrading Dell CSI Driver(s) with CSM for Authorization enabled
Given a setup where the CSM for Authorization proxy server is already upgraded to the latest version, follow the upgrade instructions for the applicable CSI Driver(s) to upgrade the driver and the CSM for Authorization sidecar