Authorization v2.0

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.

Upgrade CSM Authorization

This section outlines the upgrade steps for Container Storage Modules (CSM) for Authorization. The upgrade of CSM for Authorization is handled in 2 parts:

Upgrading the Authorization proxy server
Upgrading CSI Driver, Authorization sidecar with Authorization module enabled

Upgrade Notice: CSM v1.14 → CSM v1.15 (Authorization v2.2.0 → v2.3.0)

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.

Install a supported External Secret Provider to integrate with the Secrets Store CSI Driver. For guidance on setting up Vault, refer to our Vault installation guide. For Conjur, refer to our Conjur installation guide.
Install the Secrets Store CSI Driver enabling the Sync as Kubernetes Secret and Secret Auto Rotation features.

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.

For OpenShift environments, label the namespace:

kubectl label namespace authorization \
 pod-security.kubernetes.io/enforce=privileged \
 security.openshift.io/MinimallySufficientPodSecurityStandard=privileged \
 --overwrite

Minimal SecretProviderClass configuration: includes only array-based credentials

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 system
username: "username"
password: "password"

Create the Secret:

kubectl create secret generic storage-secret -n authorization --from-file=storage-secret.yaml

Upgrading the Authorization Proxy Server

Modifying the existing Authorization Proxy Server installation directly via kubectl edit

Example: Editing the Authorization Proxy Server Configuration

If the Authorization Proxy Server is deployed in the authorization namespace, retrieve the CSM object name using:
```
kubectl get csm -n authorization
```
Use the retrieved object name in the kubectl get command to modify its configuration
```
kubectl edit csm <object-name> -n <module-namespace>
```
For instance, if the object name is authorization and the namespace is also authorization, run:
```
kubectl edit csm authorization -n authorization
```
Modify the installation configuration:

When upgrading to the latest version, ensure the following updates are made to your deployment configuration:
- Update the configVersion for the CSM Authorization Proxy Server to reflect the new release.
- Update container images to their latest versions:
  - proxy service
  - tenant service
  - role service
  - storage service
  - authorization controller
  - redis
- Review and revise configuration parameters:
  - Add any newly introduced parameters.
  - Remove any parameters that have been deprecated or are no longer supported.
Modify the Authorization ConfigMap parameters:

The latest configuration values are available in the updated sample Custom Resource for Authorization.

To apply these changes, edit the csm-config-params ConfigMap using:
```
kubectl edit configmap csm-config-params -n authorization
```
As part of the upgrade from CSM v1.14 → v1.15 (Authorization v2.2.0 → v2.3.0), modify the existing csm-config-params ConfigMap in the authorization namespace to reflect the new unified concurrency setting.

Remove:
```
CONCURRENT_POWERFLEX_REQUESTS: 10
CONCURRENT_POWERSCALE_REQUESTS: 10
```
Add:
```
CONCURRENT_STORAGE_REQUESTS: 10
```
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 CSI Driver, Authorization sidecar with Authorization module enabled

Modifying the existing driver and module installation directly via kubectl edit
```
kubectl get csm -n <driver-namespace>
```
For example - If the CSI PowerFlex driver is installed in vxflexos namespace then run this command to get the object name
```
kubectl get csm -n vxflexos
```
use the object name in kubectl edit command.
```
kubectl edit csm <object-name> -n <driver-namespace>
```
For example - If the object name is vxflexos then use the name as vxflexos and if the driver is installed in vxflexos namespace, then run this command to edit the object
```
kubectl edit csm vxflexos -n vxflexos
```
Modify the installation
- Update the driver config version and image tag
- Update the Authorization config version and karavi-authorization-proxy image.

Note:

In Authorization module upgrade, only n-1 to n upgrade is supported, e.g. if the current authorization version is v2.1.x, it can be upgraded to 2.2.x.

Feedback

Was this page helpful?

Thank you for your feedback!