Cuando creas un clúster de bases de datos, se genera un certificado de servidor firmado por la AC de GDC predeterminada y se configura para que lo use tu servidor de bases de datos. Para firmar y subir un certificado de su base de datos emitido por su propia infraestructura de clave pública, siga este procedimiento. Para usar esta función, el emisor predeterminado de tu organización debe estar en el modo de certificado BYO.
API
Una vez que hayas creado el clúster de bases de datos y esté listo, guarda la solicitud de firma de certificado generada en un archivo.
kubectl get certificate.pki.security.gdc.goog \ dbs-DBENGINE_SHORT_NAME-cert-request-DBCLUSTER_NAME \ -n USER_PROJECT -o jsonpath='{.status.byoCertStatus.csrStatus.csr}' \ | base64 -d > DBCLUSTER_NAME.csr
Crea un archivo de extensiones de CSR que contenga los SANs de tu clúster de base de datos.
export SAN=$(openssl req -in DBCLUSTER_NAME.csr -noout -text | grep 'DNS:' | sed -s 's/^[ ]*//')
echo "keyUsage=digitalSignature,keyEncipherment extendedKeyUsage=serverAuth,clientAuth subjectAltName=${SAN:?}" > DBCLUSTER_NAME-csr.ext
Con el archivo CSR y el archivo de extensión, genera el certificado firmado por tu AC. En el ejemplo de código se usa
openssl
, pero este paso se puede completar con otras herramientas.openssl x509 -req -in DBCLUSTER_NAME.csr -days 365 \ -CA CA_CERTIFICATE_FILE -CAkey CA_PRIVATE_KEY_FILE \ -CAcreateserial -extfile DBCLUSTER_NAME-csr.ext \ -out DBCLUSTER_NAME-signed.crt
Actualiza el recurso de certificado con el certificado firmado y el certificado de la AC.
echo "spec: byoCertificate: certificate: $(base64 -w0 DBCLUSTER_NAME-signed.crt) ca: $(base64 -w0 CA_CERTIFICATE_FILE)" > patch.txt
kubectl patch certificate.pki.security.gdc.goog \ dbs-DBENGINE_SHORT_NAME-cert-request-DBCLUSTER_NAME \ -n USER_PROJECT --patch-file patch.txt --type='merge'
Verifica que el certificado haya alcanzado el estado "Listo" después de la subida.
kubectl get certificate.pki.security.gdc.goog \ dbs-DBENGINE_SHORT_NAME-cert-request-DBCLUSTER_NAME \ -n USER_PROJECT -o json | jq -r ' .status.conditions[] | select( .type as $id | "Ready" | index($id))'
La salida debería ser similar a la siguiente:
{ "lastTransitionTime": "2024-05-03T08:42:10Z", "message": "Certificate is issued", "observedGeneration": 2, "reason": "Issued", "status": "True", "type": "Ready" }
Solo si usas una base de datos Oracle, detén y reinicia el clúster de la base de datos para que se vuelva a cargar la configuración SSL del receptor.
Haz los cambios siguientes:
DBENGINE_SHORT_NAME
: el nombre abreviado del motor de la base de datos. Se trata deal
(AlloyDB Omni),pg
(PostgreSQL) uora
(Oracle).DBCLUSTER_NAME
: el nombre del clúster de la base de datos.USER_PROJECT
: el nombre del proyecto de usuario en el que se creó el clúster de base de datos.CA_CERTIFICATE_FILE
: la ruta al archivo del certificado de AC de la base de datos.CA_PRIVATE_KEY_FILE
: la ruta al archivo de clave privada de la CA de la base de datos.