Manually rotate internal certificates

Select a documentation version: 17.7.0 keyboard_arrow_down

• Current (18.1.0)
• 18.1.0
• 17.7.0
• 16.11.0
• 15.15.0

By default, the AlloyDB Omni Kubernetes operator uses 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-manager documentation, when a CA certificate associated with an issuer is rotated, the leaf certificates aren't automatically re-issued.
• cert-manager automatic 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 kubectl configured to access your Kubernetes cluster.
• Ensure that cert-manager is 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.

1. Identify the cert-manager Certificate that you want to rotate. These objects are in your DBCluster namespace and the namespace where the AlloyDB Omni operator is installed. The names of CA certificates have the prefix dbs-al-ca , while leaf certificates have the prefix dbs-al-cert . In the remaining steps, use the name of the associated secret from the output.

    kubectl  
   get  
   certificate  
    CERTIFICATE_NAME 
     
   -n  
    NAMESPACE 
     
   -o  
   wide 
   

2. Before you trigger rotation, back up the certificate secret:

    kubectl  
   get  
   secret  
    SECRET_NAME 
     
   -n  
    NAMESPACE 
     
   -o  
   yaml > 
    SECRET_NAME 
   - NAMESPACE 
   .yaml.bak 
   

3. Delete the certificate secret:

    kubectl  
   delete  
   secret  
    SECRET_NAME 
     
   -n  
    NAMESPACE 
    
   

4. Wait for cert-manager to 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:

1. Check the certificate secret. The creationTimestamp value must reflect the time after you manually rotated the certificate:

    kubectl  
   get  
   secret  
    SECRET_NAME 
     
   -n  
    NAMESPACE 
     
   -o  
   yaml 
   

2. Examine the Certificate status. Verify that the notBefore and notAfter dates in the status section are correct:

    kubectl  
   describe  
   certificate  
    CERTIFICATE_NAME 
     
   -n  
    NAMESPACE 
    
   

What's next

• Manage certificates .