Manage Certificates and Keys

Certificates Authorities

Several certificates authorities are generated when you create a cluster. You can retrieve the public certificate for some of these authorities by using the exo compute sks authority-cert <CLUSTER-NAME|ID> <AUTHORITY> command in the CLI.

The authorities are:

• kubelet: the authority generating certificates for the Kubelet daemon running on the workers.
• aggregation: the authority used by the aggregation layer.
• control-plane: the authority of the cluster control plane.
• operators: the authority signing the X.509 client certificates embedded in the kubeconfig files we generate for you, with exo compute sks kubeconfig through the generate-sks-cluster-kubeconfig API call. The API server trusts it as a client CA (enable-operators-ca, enabled by default), which is what makes those kubeconfigs work. It can be rotated, see Rotate the operators CA.
• etcd: the authority securing the communications with the etcd datastore backing your control plane. It is entirely internal to the managed control plane and never exposed.

Only kubelet, aggregation and control-plane can be retrieved with authority-cert.

Addon credentials

The Exoscale Cloud Controller Manager (CCM), the Exoscale Container Storage Interface (CSI) and the Karpenter addons each need a set of credentials to communicate with the platform. An IAM role and api key are created automatically per-addon and per-cluster on your account when you create or update a cluster with addons selected. The lifecycle of these credentials is managed by Exoscale. They are deleted automatically once the cluster is deleted.

Credentials managed by Exoscale SKS all have following naming scheme: sks-<addon>-<cluster-id> eg. sks-ccm-859ece7e-f4ec-4eab-a77f-d06a1cfc08fd

You can list them on your account with:

exo iam api-key list

Rotation

SKS lets you rotate two different things, and they have very different consequences:

• The addon credentials (CCM, CSI, Karpenter): the IAM keys Exoscale uses on your behalf. Rotating them is transparent for your users.
• The operators CA: the authority signing the client certificates in your kubeconfig files. Rotating it revokes kubectl access for everyone, see Rotate the operators CA.

Why rotate the addon credentials

Rotation replaces a credential with a freshly generated one and invalidates the previous one.

You can use this feature when:

• The credential was deleted or altered by mistake. Deleting the sks-ccm-* API key or its IAM role breaks the addon: no LoadBalancer service is reconciled anymore, and nodes TLS bootstrapping fails. Similarly, no volume is provisioned through the CSI, or no node is created by Karpenter. Rotating recreates the role and the key and re-injects them into the cluster.
• You suspect a leak or a compromise. A key that appeared in a log, a screenshot, a support ticket or a git repository should be considered public. Rotating revokes it immediately.
• Your security policy requires periodic renewal. Exoscale does not expire these credentials automatically, so a scheduled rotation is yours to trigger, for example as part of a quarterly review or an audit requirement.
• Someone with access to the credentials left the team. Rotating closes the door without touching the rest of the cluster.

Rotating an addon credential only concerns the credentials Exoscale manages for your cluster. It does not touch your own API keys, your kubeconfig, or your workloads.

What happens during an addon credential rotation

Each rotation is an asynchronous operation on the cluster:

1. A new IAM role and API key are generated.
2. They are pushed to the addon running in your cluster (for ccm and csi) or in our managed control plane fleet platform (for Karpenter).
3. The previous credential is revoked.

The cluster moves to a transient state while this happens (rotating-ccm-credentials, rotating-csi-credentials or rotating-karpenter-credentials) and returns to running once the operation is over. Check it with:

exo compute sks show --zone de-fra-1 my-cluster

Rotate the CCM credentials

The Exoscale Cloud Controller Manager manages LoadBalancer services (Network Load Balancers), node TLS bootstrapping and Node metadata. Rotate its credentials with:

exo compute sks rotate-ccm-credentials --zone de-fra-1 my-cluster

Rotate the CSI credentials

The Exoscale Container Storage Interface provisions and attaches Block Storage volumes to your nodes. Rotate its credentials with:

exo compute sks rotate-csi-credentials --zone de-fra-1 my-cluster

Rotate the Karpenter credentials

Karpenter creates and deletes compute instances on your behalf, so it holds the most privileged addon role. Rotate its credentials with:

exo compute sks rotate-karpenter-credentials --zone de-fra-1 my-cluster

Rotate the operators CA

Unlike the three operations above, no IAM credential is involved here. This replaces the certificate authority that signs the client certificates in the kubeconfig files generated for your cluster, and updates the trust store of the API server accordingly.

exo compute sks rotate-operators-ca --zone de-fra-1 my-cluster

exo compute sks kubeconfig --zone de-fra-1 my-cluster admin -g system:masters > $HOME/.kube/my-cluster.config

This is the way to revoke cluster access before previous certificates expire. Kubeconfigs are issued with a TTL, 30 days by default on the portal, and there is no per-certificate revocation: rotating the CA is what invalidates them all at once. Use it when:

• A kubeconfig leaked, was committed to a repository, or sat on a lost or compromised machine.
• An administrator left the team and held a long-lived kubeconfig.
• Your security policy mandates a periodic CA renewal.

Plan the rotation with the people and pipelines that need access, so new kubeconfigs are issued right after.