cert-manager to provision a set of TLS certificates for each database cluster. In addition to the database server certificate, the operator creates certificates for control plane components to secure internal connections.
While cert-manager automates certificate renewals based on the duration and renewBefore fields of a Certificate object, you might need to manually trigger a certificate rotation in the following scenarios:
- A private key is compromised.
- A CA certificate is rotated. According to
cert-managerdocumentation, when a CA certificate associated with an issuer is rotated, the leaf certificates aren't automatically re-issued. cert-managerautomatic re-issuance fails. Although rare, if automatic re-issuance doesn't trigger due to specific conditions described in the cert-manager FAQ, you must trigger a manual rotation.
Before you begin
- Ensure you have
kubectlconfigured to access your Kubernetes cluster. - Ensure that
cert-manageris running on your Kubernetes cluster.
Manual certificate rotation
To manually trigger certificate rotation, delete the secret associated with the cert-manager Certificate object. The cert-manager controller reconciles the object and re-issues the certificate, which creates a new secret. Workloads associated with the AlloyDB Omni operator automatically reload their TLS configurations to use the new certificate.
Identify the
cert-managerCertificatethat you want to rotate. These objects are in yourDBClusternamespace and the namespace where the AlloyDB Omni operator is installed. The names of CA certificates have the prefixdbs-al-ca, while leaf certificates have the prefixdbs-al-cert. In the remaining steps, use the name of the associated secret from the output.kubectl get certificate CERTIFICATE_NAME -n NAMESPACE -o wideBefore you trigger rotation, back up the certificate secret:
kubectl get secret SECRET_NAME -n NAMESPACE -o yaml > SECRET_NAME-NAMESPACE.yaml.bakDelete the certificate secret:
kubectl delete secret SECRET_NAME -n NAMESPACEWait for
cert-managerto recreate the certificate secret:kubectl get secret SECRET_NAME -n NAMESPACE -w
Verify certificate rotation
After you manually rotate the certificates, verify that the new certificates are in use:
Check the certificate secret. The
creationTimestampvalue must reflect the time after you manually rotated the certificate:kubectl get secret SECRET_NAME -n NAMESPACE -o yamlExamine the
Certificatestatus. Verify that thenotBeforeandnotAfterdates in the status section are correct:kubectl describe certificate CERTIFICATE_NAME -n NAMESPACE