Skip to main content

​
Overview

Every K8SaaS cluster has a dedicated certificate authority (CA) generated at provisioning time. The CA signs all cluster component certificates (API server, etcd, kubelet) and kubeconfig client certificates. Administrators rotate the CA when certificates approach expiry, when credentials are suspected compromised, or after a security incident.
Rotating a cluster CA invalidates all existing kubeconfigs for that cluster. All project users with access to the cluster must re-download their credentials after rotation. Notify all users before performing a CA rotation.

​
View Cluster CA

Navigate to Admin → Containers → Clusters, click a cluster, and select Actions → Show CA to view the cluster’s current CA certificate (public key only).

​
Rotate the Cluster CA

CA rotation is irreversible. Existing kubeconfigs stop working immediately after rotation. Plan rotation during a maintenance window and prepare user communication in advance.

Notify users

Send advance notice to all users with cluster access that their kubeconfigs will be invalidated at the scheduled rotation time.

Initiate rotation

Navigate to Admin → Containers → Clusters, click the cluster, and select Actions → Rotate CA. Confirm the rotation.The cluster enters UPDATE_IN_PROGRESS during CA regeneration.

Wait for completion

Wait for the cluster to return to UPDATE_COMPLETE status.

Direct users to refresh

Notify all users to re-download their kubeconfig:
Refresh kubeconfig (user command)
openstack coe cluster config prod-cluster-01 \
  --dir ~/.kube \
  --force
All users can connect to the cluster with the new kubeconfig.

​
Certificate Expiry Planning

Plan CA rotations proactively to avoid service disruption from expired certificates.
CertificateDefault ValidityAction Required
Cluster CA10 yearsRotate 90 days before expiry
API server TLS1 year (auto-renewed)Monitor via openssl x509 -noout -dates
Node kubelet certificates1 year (auto-renewed)Ensure auto_healing_enabled=true in template
Audit all cluster CA expiry dates
for cluster in $(openstack coe cluster list -f value -c name); do
  echo -n "$cluster: "
  openstack coe ca show $cluster \
    | grep -A 20 "BEGIN CERTIFICATE" \
    | openssl x509 -noout -enddate 2>/dev/null
done

​
Xloud Key Management Integration

For the highest security posture, store cluster CA private keys in Xloud Key Management rather than in the K8SaaS database.
Xloud Key Management must be deployed and the magnum service account must have the creator role on the Key Management service before enabling this integration.

Open XDeploy Configuration

Navigate to XDeploy → Configuration and select the Advance Features tab.

Enable KMS

Set Enable KMS to Yes. This deploys the Xloud Key Management service and configures service account integration.

Set certificate manager type

Open XDeploy → Advanced Configuration, select magnum in the Service Tree, then open or create kubernetes.conf. Add the following in the Code Editor:
kubernetes.conf
[certificate]
cert_manager_type = barbican
Click Save Current File.

Deploy the changes

Navigate to XDeploy → Operations and run a Reconfigure for the Kubernetes and Key Management services.
K8SaaS is configured to store CA private keys in Xloud Key Management.

​
Next Steps

Security

Configure RBAC and node security groups alongside certificate management.

Monitoring

Monitor certificate expiry and cluster health across all projects.

Cluster Upgrades (User)

Advise users on refreshing kubeconfigs after upgrades and CA rotations.

Key Manager

Configure Xloud Key Management for secure CA private key storage.