Rotate security certificates
You may need to rotate the node, client, or CA certificates in the following scenarios:- The node, client, or CA certificates are expiring soon.
- Your organization’s compliance policy requires periodic certificate rotation.
- The key (for a node, client, or CA) is compromised.
- You need to modify the contents of a certificate, for example, to add another DNS name or the IP address of a load balancer through which a node can be reached. In this case, you would need to rotate only the node certificates.
Example: Rotate certificates signed with cockroach cert
If you previously , follow these steps to rotate the certificates using the same CA:
-
Create a new client certificate and key pair for the root user, overwriting the previous certificate and key:
-
Upload the new client certificate and key to the Kubernetes cluster as a new secret, renaming them to the filenames required by the CockroachDB operator:
-
Create a new certificate and key pair for your CockroachDB nodes, overwriting the previous certificate and key. Specify the namespace you used when . This example uses the
cockroach-nsnamespace: -
Upload the new node certificate and key to the Kubernetes cluster as a new secret, renaming them to the filenames required by the CockroachDB operator:
-
Add
cockroachdb.tls.externalCertificates.certificates.nodeClientSecretNameandcockroachdb.tls.externalCertificates.certificates.nodeSecretNameto the values file used to : -
Check that the secrets were created on the cluster:
Remember that
nodeSecretName and nodeClientSecretName in the operator configuration must specify these secret names. For details, see the .-
Apply the new settings to the cluster:
The pods will terminate and restart one at a time, using the new certificates. You can observe this process:
-
Delete the existing client secret that is no longer in use:
-
Delete the existing node secret that is no longer in use:
Secure the webhooks
The operator ships with both mutating and validating webhooks. Communication between the Kubernetes API server and the webhook service must be secured with TLS. By default, the CockroachDB operator searches for the TLS secretcockroach-operator-certs, which contains a CA certificate. If the secret is not found, the operator auto-generates cockroach-operator-certs with a CA certificate for future runs.
The operator then generates a one-time server certificate for the webhook server that is signed with cockroach-operator-certs. Finally, the CA bundle for both mutating and validating webhook configurations is patched with the CA certificate.
You can also use your own certificate authority rather than cockroach-operator-certs. Both the certificate and key files you generate must be PEM-encoded. See the following example.
Example: Using OpenSSL to secure the webhooks
These steps demonstrate how to use the openssl genrsa and openssl req subcommands to secure the webhooks on a running Kubernetes cluster:-
Generate a 4096-bit RSA private key:
-
Generate an X.509 certificate, valid for 10 years. You will be prompted for the certificate field values.
-
Create the secret, making sure that you are in the correct namespace:
-
Remove the certificate and key from your local environment:
-
Roll the operator deployment to ensure a new server certificate is generated:

