Helm

Deprecation Notice Pre-Wire: 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.

Roles

Role data is stored in the common Config Map.

Steps to execute in the existing Authorization deployment

  1. Save the role data by saving the common configMap to a file.
kubectl -n <authorization-namespace> get configMap common -o yaml > roles.yaml

Steps to execute in the Authorization deployment to restore

  1. Delete the existing common configMap.
kubectl -n <authorization-namespace> delete configMap common
  1. Apply the file containing the backed-up role data.
kubectl apply -f roles.yaml
  1. Restart the proxy-server deployment.
kubectl -n <authorization-namespace> rollout restart deploy/proxy-server
deployment.apps/proxy-server restarted

Storage

Storage data is stored in the karavi-storage-secret Secret.

Steps to execute in the existing Authorization deployment

  1. Save the storage data by saving the karavi-storage-secret Secret to a file.

kubectl -n <authorization-namespace> get secret karavi-storage-secret -o yaml > storage.yaml

Steps to execute in the Authorization deployment to restore

  1. Delete the existing karavi-storage-secret secret.
kubectl -n <authorization-namespace> delete secret karavi-storage-secret
  1. Apply the file containing the storage data created in step 1.
kubectl apply -f storage.yaml
  1. Restart the proxy-server deployment.
kubectl -n <authorization-namespace> rollout restart deploy/proxy-server
deployment.apps/proxy-server restarted

Tenants, Quota, and Volume ownership

Redis is used to store application data regarding tenants, quota, and volume ownership with the Storage Class csm-authorization-local-storage or the one specified in the redis.storageClass parameter in the values file.

The Persistent Volume for Redis is provisioned by the above Storage Class with the redis-primary-pv-claim Persistent Volume Claim. See the example.

kubectl get persistentvolume
NAME                CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                                      STORAGECLASS    REASON   AGE
k8s-ab74921ab9      8Gi        RWO            Delete           Bound      authorization/redis-primary-pv-claim       <storage-class>          112m

Steps to execute in the existing Authorization deployment

  1. Create a backup of this volume, typically via snapshot and/or replication, and create a Persistent Volume Claim using this backup by following the Storage Class’s provisioner documentation.

Steps to execute in the Authorization deployment to restore

  1. Edit the redis-primary Deployment to use the Persistent Volume Claim associated with the backup by running:
kubectl -n <authorization-namespace> edit deploy/redis-primary

The Deployment has a volumes field that should look like this:

volumes:
- name: redis-primary-volume
  persistentVolumeClaim:
    claimName: redis-primary-pv-claim

Replace the value of claimName with the name of the Persisent Volume Claim associated with the backup. If the new Persisent Volume Claim name is redis-backup, you would edit the deployment to look like this:

volumes:
- name: redis-primary-volume
  persistentVolumeClaim:
    claimName: redis-backup

Once saved, Redis will now use the backup volume.