Gerir certificados

Selecione uma versão da documentação:

Esta página descreve como usar emissores de certificados personalizados para gerir certificados Transport Layer Security (TLS) no cluster de base de dados AlloyDB Omni baseado no Kubernetes.

Por predefinição, o operador do AlloyDB Omni Kubernetes usa o cert-manager para aprovisionar um conjunto de certificados TLS para cada cluster de base de dados. Além do certificado do servidor de base de dados, o operador também cria certificados para componentes do plano de controlo para garantir que as ligações internas também são seguras. Por predefinição, cada certificado é assinado por um emissor gerido pelo operador.

A partir da versão 1.6.0 do operador do AlloyDB Omni, se preferir que todos os certificados, incluindo os dos componentes do plano de controlo, sejam encadeados de volta à sua própria AC raiz fidedigna, pode configurar o operador para usar um emissor à sua escolha. Isto permite-lhe encadear todos os certificados à sua própria infraestrutura de chave pública (PKI), incluindo os certificados usados para a funcionalidade do plano de controlo, sem expor os detalhes de implementação de cada entidade interna.

Antes de começar

Para configurar um emissor de certificados, primeiro tem de criar um emissor do cert-manager do tipo ClusterIssuer ou Issuer associado à CA com a qual quer assinar os seus certificados. O operador do AlloyDB Omni faz referência a este emissor quando cria certificados.

Configure emissores personalizados

Pode configurar emissores de certificados personalizados para o cluster de base de dados, o operador AlloyDB Omni e o PgBouncer.

Certificados de cluster de base de dados

Esta funcionalidade requer que o controlPlaneAgentsVersion do cluster da base de dados relevante no respetivo manifesto seja 1.6.0 ou superior.

Existem dois campos de especificação do cluster da base de dados para configurar os emissores de certificados:

  • spec.primarySpec.dataPlaneCertIssuer: referência ao emissor do cert-manager que aprovisiona certificados do plano de dados. A AC emissora é aquela em que o cliente da base de dados pode confiar para validar a base de dados durante uma ligação TLS.

  • spec.primarySpec.controlPlaneAgentsCertIssuer: referência ao emissor do cert-manager que aprovisiona certificados do plano de controlo. Estes certificados são usados para ligações internas.

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

Substitua o seguinte:

  • DATA_PLANE_ISSUER_NAME: nome do emissor do cert-manager que aprovisiona certificados do plano de dados, como para o servidor da base de dados.

  • DATA_PLANE_ISSUER_KIND: tem de ser Issuer ou ClusterIssuer.

  • CONTROL_PLANE_ISSUER_NAME: nome do emissor do cert-manager que aprovisiona certificados do plano de controlo para componentes internos.

  • CONTROL_PLANE_ISSUER_KIND: tem de ser Issuer ou ClusterIssuer.

Certificados de operador

Os passos para configurar um emissor do cert-manager para certificados de operador dependem do método usado para instalar o AlloyDB Omni.

Configure através do Helm

Se instalar o operador do AlloyDB Omni versão 1.6.0 ou posterior pela primeira vez, use a instalação do Helm e defina os valores adequados. Isto pressupõe que segue as instruções de instalação.

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 já tiver o operador instalado e precisar de definir o emissor do certificado, use helm upgrade para definir os valores adequados:

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

Substitua o seguinte:

  • OPERATOR_CERT_ISSUER_NAME: nome da entidade emissora do cert-manager que aprovisiona o certificado do operador, que é usado para ligações internas.

  • OPERATOR_CERT_ISSUER_KIND: tem de ser Issuer ou ClusterIssuer.

Configure através do Operator Lifecycle Manager

Se usou o Operator Lifecycle Manager (OLM) para instalar o operador do AlloyDB Omni, pode modificar o campo spec.config.env do recurso de subscrição para definir as variáveis de ambiente CERT_MANAGER_ISSUER_NAME e CERT_MANAGER_ISSUER_KIND da implementação do operador.

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

Substitua o seguinte:

  • OPERATOR_CERT_ISSUER_NAME: nome da entidade emissora do cert-manager que aprovisiona o certificado do operador, que é usado para ligações internas.

  • OPERATOR_CERT_ISSUER_KIND: tem de ser Issuer ou ClusterIssuer.

Certificados do PgBouncer

Para suportar emissores personalizados, o controlador do PgBouncer pode verificar o campo spec.primarySpec.tls.dataPlaneCertIssuer do DBCluster e usá-lo para aprovisionar o certificado do PgBouncer. Isto garante que o PgBouncer usa um certificado da mesma CA que a base de dados.

Validar

Para verificar se a implementação do operador está em bom estado e se as variáveis de ambiente CERT_MANAGER_ISSUER_NAME e CERT_MANAGER_ISSUER_KIND estão definidas, execute o seguinte comando:

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

Para verificar se é usado o emissor correto, inspecione os objetos Certificate da seguinte forma:

kubectl get certificate -n NAMESPACE

Verifique o campo issuerRef no resultado de cada certificado para confirmar que corresponde ao seu emissor personalizado.