Secrets And Credentials

Testudo handles several high-value credentials. Production deployments should avoid writing real credentials to public values files, screenshots, or logs.

Credential Types

Credential	Purpose	Guidance
Image pull secret	Pull operator/server/web images	Reuse an existing Secret; avoid public values
Object storage access key	Access backup bucket	Least privilege, rotation, bucket audit
Remote cluster kubeconfig/token	Access source/target cluster APIs	Least privilege, one credential per cluster, rotation
JWT secret	Sign Server access/refresh tokens	Replace the default in production
License Secret	Platform license	Install through platform API or private values
Webhook TLS Secret	Admission webhook TLS	Prefer cert-manager

Helm Values Rules

Do not commit real credentials to public release packages. Prefer:

imagePullSecret:
  existingSecret: default-secret

If Helm must create a Secret, put the values only in a private values file and keep it out of public repositories.

Object Storage Credentials

The object storage account should have:

• Read/write permissions for the target bucket.
• List permission.
• Required multipart upload permissions.

Do not use a cloud root access key. Create a dedicated account scoped to the disaster recovery bucket.

Remote Cluster Credentials

Source and target clusters can be registered with kubeconfig or token+endpoint. Production guidance:

• Use separate credentials per business cluster.
• Separate credentials across environments.
• Grant only protected namespace and Velero permissions.
• Confirm whether remote Velero resources should be removed before deleting a cluster.

Validation And Rotation

After rotating credentials, verify:

kubectl -n disaster-system get clusters.testudo.softcdata.com
kubectl -n disaster-system get storagerepositories.testudo.softcdata.com
kubectl -n disaster-system get disasterinstances.testudo.softcdata.com

Also check cluster connectivity, storage repository status, and latest DataSync/ResourceSync state in the console.