Gerenciar certificados

Selecione uma versão da documentação:

Nesta página, descrevemos como usar emissores de certificados personalizados para gerenciar certificados Transport Layer Security (TLS) no cluster de banco de dados do AlloyDB Omni baseado no Kubernetes.

Por padrão, o operador do AlloyDB Omni no Kubernetes usa o cert-manager para provisionar um conjunto de certificados TLS para cada cluster de banco de dados. Além do certificado do servidor de banco de dados, o operador também cria certificados para componentes do plano de controle para garantir que as conexões internas também sejam seguras. Por padrão, cada certificado é assinado por um emissor gerenciado pelo operador.

A partir da versão 1.6.0 do operador do AlloyDB Omni, se você preferir que todos os certificados, incluindo os dos componentes do plano de controle, sejam encadeados de volta à sua própria CA raiz confiável, configure o operador para usar um emissor de sua escolha. Isso permite encadear todos os certificados à sua própria infraestrutura de chave pública (PKI), incluindo os usados para a funcionalidade do plano de controle, sem expor os detalhes de implementação de cada entidade interna.

Antes de começar

Para configurar um emissor de certificado, primeiro crie um emissor do cert-manager do tipo ClusterIssuer ou Issuer associado à CA que você quer usar para assinar seus certificados. O operador do AlloyDB Omni faz referência a esse emissor ao criar certificados.

Configurar emissores personalizados

É possível configurar emissores de certificados personalizados para o cluster de banco de dados, o operador do AlloyDB Omni e o PgBouncer.

Certificados de cluster de banco de dados

Esse recurso exige que o controlPlaneAgentsVersion relevante do cluster de banco de dados no manifesto seja 1.6.0 ou mais recente.

Há dois campos de especificação do cluster de banco de dados para configurar emissores de certificados:

  • spec.primarySpec.dataPlaneCertIssuer: referência ao emissor do cert-manager que provisiona certificados do plano de dados. A CA emissora é aquela em que o cliente do banco de dados pode confiar para verificar o banco durante uma conexão TLS.

  • spec.primarySpec.controlPlaneAgentsCertIssuer: referência ao emissor do cert-manager que provisiona certificados do plano de controle. Esses certificados são usados para conexõ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:

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

  • DATA_PLANE_ISSUER_KIND: precisa ser Issuer ou ClusterIssuer.

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

  • CONTROL_PLANE_ISSUER_KIND: precisa ser Issuer ou ClusterIssuer.

Certificados do operador

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

Configurar usando o Helm

Se você estiver instalando o operador do AlloyDB Omni versão 1.6.0 ou mais recente pela primeira vez, use a instalação do Helm e defina os valores apropriados. Isso pressupõe que você siga 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 você já tiver o operador instalado e precisar definir a autoridade certificadora, 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:

  • OPERATOR_CERT_ISSUER_NAME: nome do emissor do cert-manager que provisiona o certificado do operador, usado para conexões internas.

  • OPERATOR_CERT_ISSUER_KIND: precisa ser Issuer ou ClusterIssuer.

Configurar usando o Operator Lifecycle Manager

Se você usou o Operator Lifecycle Manager (OLM) para instalar o operador do AlloyDB Omni, modifique o campo spec.config.env do recurso de assinatura para definir as variáveis de ambiente CERT_MANAGER_ISSUER_NAME e CERT_MANAGER_ISSUER_KIND da implantaçã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:

  • OPERATOR_CERT_ISSUER_NAME: nome do emissor do cert-manager que provisiona o certificado do operador, usado para conexões internas.

  • OPERATOR_CERT_ISSUER_KIND: precisa ser Issuer ou ClusterIssuer.

Certificados do PgBouncer

Para oferecer suporte a emissores personalizados, o controlador do PgBouncer pode verificar o campo spec.primarySpec.tls.dataPlaneCertIssuer do DBCluster e usá-lo para provisionar o certificado do PgBouncer. Isso garante que o PgBouncer use um certificado da mesma CA do banco de dados.

Verificar

Para verificar se a implantação do operador está íntegra 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 o emissor correto está sendo usado, inspecione os objetos de certificado da seguinte maneira:

kubectl get certificate -n NAMESPACE

Verifique o campo issuerRef na saída de cada certificado para confirmar se ele corresponde ao seu emissor personalizado.