Gestisci certificati

Seleziona una versione della documentazione:

Questa pagina descrive come utilizzare gli emittenti di certificati personalizzati per gestire i certificati Transport Layer Security (TLS) nel cluster di database AlloyDB Omni basato su Kubernetes.

Per impostazione predefinita, l'operatore Kubernetes di AlloyDB Omni utilizza cert-manager per eseguire il provisioning di un insieme di certificati TLS per ogni cluster di database. Oltre al certificato del server di database, l'operatore crea anche certificati per i componenti del control plane per garantire che anche le connessioni interne siano sicure. Per impostazione predefinita, ogni certificato è firmato da un emittente gestito dall'operatore.

A partire dalla versione 1.6.0 dell'AlloyDB Omni operator, se preferisci che tutti i certificati, inclusi quelli per i componenti del control plane, siano concatenati alla tua CA radice attendibile, puoi configurare l'operator in modo che utilizzi un emittente di tua scelta. In questo modo, puoi concatenare tutti i certificati alla tua infrastruttura a chiave pubblica (PKI), inclusi i certificati utilizzati per la funzionalità del control plane, senza esporre i dettagli di implementazione di ogni entità interna.

Prima di iniziare

Per configurare un emittente di certificati, devi prima creare un emittente cert-manager di tipo ClusterIssuer o Issuer associato alla CA che vuoi utilizzare per firmare i certificati. L'operatore AlloyDB Omni fa riferimento a questo emittente durante la creazione dei certificati.

Configurare gli emittenti personalizzati

Puoi configurare gli emittenti di certificati personalizzati per il cluster di database, l'operatore AlloyDB Omni e PgBouncer.

Certificati del cluster di database

Questa funzionalità richiede che il valore di controlPlaneAgentsVersion del cluster di database pertinente nel relativo manifest sia 1.6.0 o superiore.

Esistono due campi delle specifiche del cluster di database per configurare gli emittenti di certificati:

  • spec.primarySpec.dataPlaneCertIssuer: riferimento all'emittente cert-manager che esegue il provisioning dei certificati del piano dati. La CA dell'emittente è quella che il client di database può considerare attendibile per verificare il database durante una connessione TLS.

  • spec.primarySpec.controlPlaneAgentsCertIssuer: riferimento all'emittente cert-manager che esegue il provisioning dei certificati del control plane. Questi certificati vengono utilizzati per le connessioni interne.

spec:
  primarySpec:
    tls:
      dataPlaneCertIssuer:
        name: DATA_PLANE_ISSUER_NAME
        kind: DATA_PLANE_ISSUER_KIND
      controlPlaneAgentsCertIssuer:
        name: CONTROL_PLANE_ISSUER_NAME
        kind: CONTROL_PLANE_ISSUER_KIND

Sostituisci quanto segue:

  • DATA_PLANE_ISSUER_NAME: nome dell'emittente cert-manager che esegue il provisioning dei certificati del piano dati, ad esempio per il server di database.

  • DATA_PLANE_ISSUER_KIND: deve essere Issuer o ClusterIssuer.

  • CONTROL_PLANE_ISSUER_NAME: nome dell'emittente cert-manager che esegue il provisioning dei certificati del control plane per i componenti interni.

  • CONTROL_PLANE_ISSUER_KIND: deve essere Issuer o ClusterIssuer.

Certificati dell'operatore

I passaggi per configurare un emittente cert-manager per i certificati dell'operatore dipendono dal metodo utilizzato per installare AlloyDB Omni.

Configurare utilizzando Helm

Se installi l'operatore AlloyDB Omni versione 1.6.0 o successive per la prima volta, utilizza l'installazione di Helm e imposta i valori appropriati. Questo presuppone che tu segua le istruzioni di installazione.

helm install alloydbomni-operator alloydbomni-operator-${OPERATOR_VERSION}.tgz \
--create-namespace \
--namespace alloydb-omni-system \
--set operatorCertIssuer.certManagerIssuerName="OPERATOR_CERT_ISSUER_NAME" \
--set operatorCertIssuer.certManagerIssuerKind="OPERATOR_CERT_ISSUER_KIND" \
--atomic \
--timeout 5m

Se l'operatore è già installato e devi impostare l'emittente di certificati, utilizza helm upgrade per impostare i valori appropriati:

helm upgrade alloydbomni-operator alloydbomni-operator-${OPERATOR_VERSION}.tgz \
--create-namespace \
--namespace alloydb-omni-system \
--set operatorCertIssuer.certManagerIssuerName="OPERATOR_CERT_ISSUER_NAME" \
--set operatorCertIssuer.certManagerIssuerKind="OPERATOR_CERT_ISSUER_KIND" \
--atomic \
--timeout 5m

Sostituisci quanto segue:

  • OPERATOR_CERT_ISSUER_NAME: nome dell'emittente cert-manager che esegue il provisioning del certificato dell'operatore, utilizzato per le connessioni interne.

  • OPERATOR_CERT_ISSUER_KIND: deve essere Issuer o ClusterIssuer.

Configurare utilizzando Operator Lifecycle Manager

Se hai utilizzato Operator Lifecycle Manager (OLM) per installare l'operatore AlloyDB Omni, puoi modificare il campo spec.config.env della risorsa Subscription per impostare le variabili di ambiente CERT_MANAGER_ISSUER_NAME e CERT_MANAGER_ISSUER_KIND del Deployment dell'operatore.

spec:
  config:
    env:
    - name: CERT_MANAGER_ISSUER_NAME
      value: OPERATOR_CERT_ISSUER_NAME
    - name: CERT_MANAGER_ISSUER_KIND
      value: OPERATOR_CERT_ISSUER_KIND

Sostituisci quanto segue:

  • OPERATOR_CERT_ISSUER_NAME: nome dell'emittente cert-manager che esegue il provisioning del certificato dell'operatore, utilizzato per le connessioni interne.

  • OPERATOR_CERT_ISSUER_KIND: deve essere Issuer o ClusterIssuer.

Certificati PgBouncer

Per supportare gli emittenti personalizzati, il controller PgBouncer controlla il campo spec.primarySpec.tls.dataPlaneCertIssuer di DBCluster e lo utilizza per eseguire il provisioning del certificato PgBouncer. Il controller PgBouncer utilizza anche gli attributi configurati in spec.primarySpec.tls.dataPlaneCertRequest per eseguire il provisioning del certificato PgBouncer. In questo modo, PgBouncer utilizza un certificato della stessa CA con gli stessi attributi del database.

Configurare gli attributi dei certificati personalizzati

Puoi personalizzare gli attributi dei certificati Transport Layer Security (TLS) generati dall'operatore, come la durata del certificato, la finestra di rinnovo, i nomi alternativi del soggetto (SAN), il nome comune e la configurazione della chiave privata.

Configura gli attributi dei certificati personalizzati nel manifest DBCluster:

  • spec.primarySpec.tls.dataPlaneCertRequest: specifica gli attributi per i certificati del piano dati (inclusi i certificati del server pgBackrest, della query di autenticazione PgBouncer e del server di database).
  • spec.primarySpec.tls.controlPlaneAgentsCertRequest: specifica gli attributi per il provisioning dei certificati del control plane. Questi certificati vengono utilizzati per le connessioni interne.

Configurare le richieste di certificati

Specifica le proprietà della richiesta nel seguente formato:

spec:
  primarySpec:
    tls:
      dataPlaneCertRequest:
        commonName: DATABASE_COMMON_NAME
        dnsNames:
        - DATABASE_DNS_NAME_1
        - DATABASE_DNS_NAME_2
        duration: DATA_PLANE_DURATION
        renewBefore: DATA_PLANE_RENEW_BEFORE
        privateKey:
          algorithm: DATA_PLANE_ALGORITHM
          size: DATA_PLANE_KEY_SIZE
          rotationPolicy: DATA_PLANE_ROTATION_POLICY
      controlPlaneAgentsCertRequest:
        duration: CONTROL_PLANE_DURATION
        renewBefore: CONTROL_PLANE_RENEW_BEFORE
        privateKey:
          algorithm: CONTROL_PLANE_ALGORITHM
          size: CONTROL_PLANE_KEY_SIZE
          rotationPolicy: CONTROL_PLANE_ROTATION_POLICY

Sostituisci quanto segue:

  • DATABASE_COMMON_NAME: (facoltativo, solo piano dati) il nome comune del certificato del database.
  • DATABASE_DNS_NAME_1, DATABASE_DNS_NAME_2: (facoltativo, solo piano dati) elenco dei nomi alternativi del soggetto (SAN) per il certificato del database.
  • DATA_PLANE_DURATION e CONTROL_PLANE_DURATION: la durata totale del certificato come stringa di durata (ad esempio, 720h0m0s per 30 giorni).
  • DATA_PLANE_RENEW_BEFORE e CONTROL_PLANE_RENEW_BEFORE: la durata prima della scadenza in cui cert-manager deve avviare un tentativo di rinnovo (ad esempio, 120h0m0s per 5 giorni).
  • DATA_PLANE_ALGORITHM e CONTROL_PLANE_ALGORITHM: l'algoritmo della chiave privata. I valori validi sono RSA, ECDSA o Ed25519.
  • DATA_PLANE_KEY_SIZE e CONTROL_PLANE_KEY_SIZE: le dimensioni della chiave privata in bit. Se l'algoritmo è RSA, i valori validi sono 4096 o 8192 (il valore predefinito è 4096). Se l'algoritmo è ECDSA, i valori validi sono 384 o 521 (il valore predefinito è 384). Se l'algoritmo è Ed25519, le dimensioni vengono ignorate.
  • DATA_PLANE_ROTATION_POLICY e CONTROL_PLANE_ROTATION_POLICY: controllano la rigenerazione della chiave privata. I valori validi sono Always o Never.

Certificati dell'operatore e del client di backup

Per personalizzare gli attributi dei certificati per l'operatore e il client di backup (che sono condivisi tra tutte le istanze in uno spazio dei nomi e non sono gestiti da una specifica del cluster di database), modifica le risorse personalizzate Certificate. L'operatore conserva queste modifiche manuali.

Verifica

Per verificare che il Deployment dell'operatore sia integro e che le variabili di ambiente CERT_MANAGER_ISSUER_NAME e CERT_MANAGER_ISSUER_KIND siano impostate, esegui il seguente comando:

kubectl get deployments local-controller-manager -n alloydb-omni-system -o yaml

Per verificare che venga utilizzato l'emittente corretto, ispeziona gli oggetti Certificate come segue:

kubectl get certificate -n NAMESPACE

Controlla il campo issuerRef nell'output di ogni certificato per verificare che corrisponda all'emittente personalizzato.