Alauda Container Platform

Changing the Platform OIDC Client Secret

ACP uses an OIDC Client Secret for authentication between platform components. You may need to rotate this secret for security compliance, periodic credential rotation, or after a potential credential leak. After updating the secret on the global cluster, the platform automatically synchronizes it to all member clusters.

TOC

PrerequisitesOIDC Secret OverviewProcedureRollback

Prerequisites

  • kubectl access to the global cluster with cluster-admin privileges.
  • All clusters managed by the platform have been upgraded to ACP v4.3.
  • The following plugins with the Agnostic life cycle have been upgraded to versions compatible with ACP v4.3:
    • Alauda Container Platform Gitops
    • Alauda Build of Kiali
    • Kubeflow Base
    • Alauda AI
  • A new client secret value prepared. It is recommended to use a cryptographically random string of at least 32 characters.
WARNING

Changing the Client Secret causes affected components to restart, resulting in temporary authentication disruptions. Plan this operation during a maintenance window.

OIDC Secret Overview

The platform OIDC credential is stored in a Kubernetes Secret with the following details:

PropertyValue
Secret Namecpaas-oidc-secret
Namespacecpaas-system

The Secret contains two data keys:

  • client-id — The OIDC client identifier, with the default value alauda-auth. Do not modify this value.
  • client-secret — The OIDC client secret. This is the value you will rotate.

Procedure

Back up the current secret

Before making changes, back up the current Secret manifest so you can roll back if needed.

kubectl get secret cpaas-oidc-secret -n cpaas-system -o yaml > cpaas-oidc-secret-backup.yaml
WARNING

The backup file contains sensitive credential data. Store it in a secure location and delete it after the operation is complete.

Record the current client-secret hash for non-plaintext verification after the update:

OLD_SECRET_SHA256="$(kubectl get secret cpaas-oidc-secret -n cpaas-system \
  -o jsonpath='{.data.client-secret}' | base64 -d | openssl dgst -sha256 -r | awk '{print $1}')"
echo "Current client-secret SHA256: ${OLD_SECRET_SHA256}"

Update the Client Secret

DANGER

Do not modify the client-id value, and do not delete and recreate the Secret. Doing so may cause cascading authentication failures across the platform.

Use one of the following methods to update only the client-secret data field.

Method 1: Using kubectl patch (recommended)

Read the new secret from secure interactive input:

read -rs NEW_CLIENT_SECRET
echo
kubectl patch secret cpaas-oidc-secret -n cpaas-system \
  --type merge \
  -p "{\"data\":{\"client-secret\":\"$(printf %s "$NEW_CLIENT_SECRET" | base64 | tr -d '\n')\"}}"
unset NEW_CLIENT_SECRET

Method 2: Using kubectl edit

Open the Secret in your default editor and replace the client-secret value with the new base64-encoded value.

kubectl edit secret cpaas-oidc-secret -n cpaas-system
TIP

You can generate the base64-encoded value in advance:

read -rs NEW_CLIENT_SECRET
echo
printf %s "$NEW_CLIENT_SECRET" | base64
unset NEW_CLIENT_SECRET

Verify that the Secret has been updated on the global cluster without exposing plaintext:

NEW_SECRET_SHA256="$(kubectl get secret cpaas-oidc-secret -n cpaas-system \
  -o jsonpath='{.data.client-secret}' | base64 -d | openssl dgst -sha256 -r | awk '{print $1}')"
echo "Updated client-secret SHA256: ${NEW_SECRET_SHA256}"
test "${OLD_SECRET_SHA256}" != "${NEW_SECRET_SHA256}" && \
  echo "Verification passed: client-secret has changed."
unset OLD_SECRET_SHA256 NEW_SECRET_SHA256

Verify component health

After the Secret is updated, the base-operator automatically synchronizes it to all member clusters. Some components that depend on the OIDC credential will restart to load the new value. In particular, verify that the frontend and apollo deployments are running normally:

kubectl get deploy -n cpaas-system frontend apollo

Verify that all Pods are READY and UP-TO-DATE. It may take several minutes for the restart to complete.

INFO

If a component fails to start, verify that the cpaas-oidc-secret Secret exists in the cpaas-system namespace and contains valid client-id and client-secret values.

Rollback

If issues occur after the Secret change, restore the previous value from the backup created in Step 1:

kubectl apply -f cpaas-oidc-secret-backup.yaml

Alternatively, if you know the previous secret value:

read -rs PREVIOUS_CLIENT_SECRET
echo
kubectl patch secret cpaas-oidc-secret -n cpaas-system \
  --type merge \
  -p "{\"data\":{\"client-secret\":\"$(printf %s "$PREVIOUS_CLIENT_SECRET" | base64 | tr -d '\n')\"}}"
unset PREVIOUS_CLIENT_SECRET

After rolling back, repeat the verification steps to confirm that all components are healthy.