Configure certificados SSL/TLS

Esta página descreve como aplicar a encriptação SSL/TLS a uma instância para garantir que todas as ligações estão encriptadas. Também pode saber mais sobre como o Cloud SQL usa certificados SSL/TLS autogeridos para ligar a instâncias do Cloud SQL de forma segura.

Vista geral

O Cloud SQL cria automaticamente um certificado de servidor quando cria a sua instância. Recomendamos que aplique todas as ligações para usar SSL/TLS.

Para validar a identidade do cliente/servidor através de certificados SSL/TLS, tem de criar um certificado de cliente e transferir os certificados para o computador anfitrião do cliente PostgreSQL.

Quando aplica o SSL a uma instância, esta não requer um reinício. No entanto, as alterações aos certificados SSL/TLS podem resultar num reinício automático da instância e podem incorrer em tempo de inatividade.

Uma alteração à configuração do modo SSL aplica-se apenas a novas ligações. Se aplicar o SSL e a sua instância tiver ligações não encriptadas existentes, as ligações permanecem ligadas e não encriptadas. Para fechar todas as ligações não encriptadas e aplicar o SSL em todas as ligações, tem de reiniciar a instância.

Aplique a encriptação SSL/TLS

Pode usar a definição Modo SSL para aplicar a encriptação SSL das seguintes formas:

  • Permitir ligações não SSL/não TLS e ligações SSL/TLS. O certificado de cliente não é validado para ligações SSL/TLS. Esta é a predefinição.

  • Permitir apenas ligações encriptadas com SSL/TLS. O certificado de cliente não é validado para ligações SSL.

  • Permita apenas ligações encriptadas com SSL/TLS e com certificados de cliente válidos.

Se selecionar Permitir ligações não SSL/não TLS e SSL/TLS para a sua instância do Cloud SQL, as ligações SSL/TLS são aceites, bem como as ligações não encriptadas e não seguras. Se não precisar de SSL/TLS para todas as ligações, as ligações não encriptadas continuam a ser permitidas. Por este motivo, se estiver a aceder à sua instância através de um IP público, recomendamos vivamente que aplique o SSL a todas as ligações.

Pode ligar-se diretamente às instâncias através de certificados SSL/TLS ou pode ligar-se através do proxy Auth do Cloud SQL ou dos conetores do Cloud SQL. Se estabelecer ligação através do proxy Auth do Cloud SQL ou dos conetores do Cloud SQL, as ligações são automaticamente encriptadas com SSL/TLS. Com o proxy Auth do Cloud SQL e os conectores do Cloud SQL, as identidades do cliente e do servidor também são validadas automaticamente, independentemente da definição do modo SSL.

Para ativar a exigência de SSL/TLS, faça o seguinte:

Consola

  1. Na Google Cloud consola, aceda à página Instâncias do Cloud SQL.

    Aceda a Instâncias do Cloud SQL

  2. Para abrir a página Vista geral de uma instância, clique no nome da instância.
  3. Clique em Associações no menu de navegação do SQL.
  4. Selecione o separador Segurança.
  5. Selecione uma das seguintes opções:
    • Permitir tráfego de rede não encriptado (não recomendado)
    • Permitir apenas ligações SSL. Esta opção só permite ligações através da encriptação SSL/TLS. Os certificados não são validados.
    • Exigir certificados de cliente fidedignos. Esta opção só permite ligações de clientes que usam um certificado de cliente válido e são encriptadas por SSL. Se um cliente ou um utilizador estabelecer ligação através da autenticação de base de dados da IAM, tem de usar o proxy Auth do Cloud SQL ou os conetores do Cloud SQL para aplicar a validação de identidade do cliente.

gcloud

   gcloud sql instances patch INSTANCE_NAME \
   --ssl-mode=SSL_ENFORCEMENT_MODE
  

Substitua SSL_ENFORCEMENT_MODE por uma das seguintes opções:

  • ALLOW_UNENCRYPTED_AND_ENCRYPTED permite ligações não SSL/não TLS e SSL/TLS. Para ligações SSL, o certificado do cliente não é validado. Este é o valor predefinido.
  • ENCRYPTED_ONLY só permite ligações encriptadas com SSL/TLS. O certificado de cliente não está validado para ligações SSL.
  • TRUSTED_CLIENT_CERTIFICATE_REQUIRED só permite ligações encriptadas com SSL/TLS e com certificados de cliente válidos. Se um cliente ou um utilizador se ligar através da autenticação de base de dados da IAM, tem de usar o proxy Auth do Cloud SQL ou os conetores do Cloud SQL para aplicar a validação da identidade do cliente.
  • Para mais informações, consulte as Definições do Cloud SQL para PostgreSQL.

Terraform

Para aplicar a encriptação SSL/TLS, use um recurso do Terraform:

resource "google_sql_database_instance" "postgres_instance" {
  name             = "postgres-instance"
  region           = "asia-northeast1"
  database_version = "POSTGRES_14"
  settings {
    tier = "db-custom-2-7680"
    ip_configuration {
      # The following SSL enforcement options only allow connections encrypted with SSL/TLS and with
      # valid client certificates. Please check the API reference for other SSL enforcement options:
      # https://cloud.google.com/sql/docs/postgres/admin-api/rest/v1beta4/instances#ipconfiguration
      ssl_mode = "TRUSTED_CLIENT_CERTIFICATE_REQUIRED"
    }
  }
  # set `deletion_protection` to true, will ensure that one cannot accidentally delete this instance by
  # use of Terraform whereas `deletion_protection_enabled` flag protects this instance at the GCP level.
  deletion_protection = false
}

Aplique as alterações

Para aplicar a configuração do Terraform num Google Cloud projeto, conclua os passos nas secções seguintes.

Prepare o Cloud Shell

  1. Inicie o Cloud Shell.
  2. Defina o Google Cloud projeto predefinido onde quer aplicar as suas configurações do Terraform.

    Só tem de executar este comando uma vez por projeto e pode executá-lo em qualquer diretório.

    export GOOGLE_CLOUD_PROJECT=PROJECT_ID

    As variáveis de ambiente são substituídas se definir valores explícitos no ficheiro de configuração do Terraform.

Prepare o diretório

Cada ficheiro de configuração do Terraform tem de ter o seu próprio diretório (também denominado módulo raiz).

  1. No Cloud Shell, crie um diretório e um novo ficheiro nesse diretório. O nome do ficheiro tem de ter a extensão .tf, por exemplo, main.tf. Neste tutorial, o ficheiro é denominado main.tf.
    mkdir DIRECTORY && cd DIRECTORY && touch main.tf
  2. Se estiver a seguir um tutorial, pode copiar o código de exemplo em cada secção ou passo.

    Copie o exemplo de código para o ficheiro main.tf criado recentemente.

    Opcionalmente, copie o código do GitHub. Isto é recomendado quando o fragmento do Terraform faz parte de uma solução completa.

  3. Reveja e modifique os parâmetros de exemplo para aplicar ao seu ambiente.
  4. Guarde as alterações.
  5. Inicialize o Terraform. Só tem de fazer isto uma vez por diretório.
    terraform init

    Opcionalmente, para usar a versão mais recente do fornecedor Google, inclua a opção -upgrade:

    terraform init -upgrade

Aplique as alterações

  1. Reveja a configuração e verifique se os recursos que o Terraform vai criar ou atualizar correspondem às suas expetativas:
    terraform plan

    Faça as correções necessárias à configuração.

  2. Aplique a configuração do Terraform executando o seguinte comando e introduzindo yes no comando:
    terraform apply

    Aguarde até que o Terraform apresente a mensagem "Apply complete!" (Aplicação concluída!).

  3. Abra o seu Google Cloud projeto para ver os resultados. Na Google Cloud consola, navegue para os seus recursos na IU para se certificar de que o Terraform os criou ou atualizou.

Eliminar as alterações

Para eliminar as alterações, faça o seguinte:

  1. Para desativar a proteção contra eliminação, no ficheiro de configuração do Terraform, defina o argumento deletion_protection como false.
    deletion_protection =  "false"
  2. Aplique a configuração do Terraform atualizada executando o seguinte comando e introduzindo yes no comando:
    terraform apply
  1. Remova os recursos aplicados anteriormente com a sua configuração do Terraform executando o seguinte comando e introduzindo yes no comando:

    terraform destroy

REST v1

  1. Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:

    • PROJECT_ID: o ID do projeto
    • SSL_ENFORCEMENT_MODE: Use uma das seguintes opções:
      • ALLOW_UNENCRYPTED_AND_ENCRYPTED: permite ligações não SSL/não TLS e SSL/TLS. Para ligações SSL, o certificado de cliente não é validado. Este é o valor predefinido.
      • ENCRYPTED_ONLY: só permite ligações encriptadas com SSL/TLS.
      • TRUSTED_CLIENT_CERTIFICATE_REQUIRED: só permite ligações encriptadas com SSL/TLS e com certificados de cliente válidos. Se um cliente ou um utilizador se ligar através da autenticação de base de dados da IAM, tem de usar o proxy Auth do Cloud SQL ou os conetores do Cloud SQL para aplicar a validação de identidade do cliente.
    • INSTANCE_ID: o ID da instância

    Método HTTP e URL:

    PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/INSTANCE_ID

    Corpo JSON do pedido:

    
    {
      "settings": {
        "ipConfiguration": {"sslMode": "SSL_ENFORCEMENT_MODE"}
      }
    }
    

    Para enviar o seu pedido, expanda uma destas opções:

    Deve receber uma resposta JSON semelhante à seguinte:

REST v1beta4

  1. Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:

    • PROJECT_ID: o ID do projeto
    • SSL_ENFORCEMENT_MODE: Use uma das seguintes opções:
      • ALLOW_UNENCRYPTED_AND_ENCRYPTED: permite ligações não SSL/não TLS e SSL/TLS. Para ligações SSL, o certificado de cliente não é validado. Este é o valor predefinido.
      • ENCRYPTED_ONLY: só permite ligações encriptadas com SSL/TLS.
      • TRUSTED_CLIENT_CERTIFICATE_REQUIRED: só permite ligações encriptadas com SSL/TLS e com certificados de cliente válidos. Se um cliente ou um utilizador se ligar através da autenticação de base de dados da IAM, tem de usar o proxy Auth do Cloud SQL ou os conetores do Cloud SQL para aplicar a validação de identidade do cliente.
    • INSTANCE_ID: o ID da instância

    Método HTTP e URL:

    PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/INSTANCE_ID

    Corpo JSON do pedido:

    {
      "settings": {
        "ipConfiguration": {"sslMode": "SSL_ENFORCEMENT_MODE"}
      }
    }
    

    Para enviar o seu pedido, expanda uma destas opções:

    Deve receber uma resposta JSON semelhante à seguinte:

Certificados de servidor

O Cloud SQL cria automaticamente um certificado de servidor quando cria a sua instância. Desde que o certificado do servidor seja válido, não precisa de gerir ativamente o certificado do servidor. O Cloud SQL permite-lhe selecionar entre três hierarquias de autoridades de certificação (AC) diferentes. A hierarquia da AC que selecionar torna-se o modo de AC do servidor da instância. Se estiver a usar a AC por instância como o modo de AC do servidor para a sua instância, os certificados do servidor têm uma data de validade de 10 anos. Se estiver a usar a CA partilhada ou a CA gerida pelo cliente como o modo de CA do servidor da sua instância, o certificado do servidor tem uma data de validade de 1 ano*. Após a data de validade, o certificado do servidor deixa de ser válido e os clientes deixam de poder estabelecer uma ligação segura à sua instância através desse certificado. Se um cliente estiver configurado para validar a AC ou o nome do anfitrião no certificado do servidor, as ligações desse cliente a instâncias do Cloud SQL com certificados do servidor expirados vão falhar. Para evitar a interrupção das ligações de cliente, faça a rotação do certificado do servidor antes de este expirar. Recebe notificações periódicas a informar que o certificado do servidor está prestes a expirar. As notificações são enviadas o seguinte número de dias antes da data de validade: 90, 30, 10, 2 e 1.

* Para a AC gerida pelo cliente, a data de validade do certificado do servidor pode ser inferior a 1 ano se tiver selecionado uma data de validade mais curta para o período de validade da sua AC.

Liste e crie certificados de servidor

Para ver os detalhes dos seus certificados de servidor na Google Cloud consola, aceda à página Ligações e clique no separador Segurança.

Na tabela de certificados, pode ver os seguintes detalhes:

  • Estado do certificado:próximo, ativo ou anterior
    • Próximo: o certificado está disponível para utilização, mas não está ativo. Para ativar o certificado, use o procedimento de rotação.
    • Ativo: o certificado está em utilização.
    • Anterior: o certificado já não está a ser usado. Para ativar o certificado, use o procedimento de reversão.
  • Criado: a data e a hora em que o certificado foi criado
  • Expira: a data e a hora em que o certificado expira

Antes de o certificado ativo expirar, pode criar um novo certificado manualmente.

Consola

Para instâncias que usam certificados de servidor autoassinados (CA por instância):

  1. Na Google Cloud consola, aceda à página Instâncias do Cloud SQL.

    Aceda a Instâncias do Cloud SQL

  2. Para abrir a página Vista geral de uma instância, clique no nome da instância.
  3. Clique em Associações no menu de navegação do SQL.
  4. Selecione o separador Segurança.
  5. Aceda à secção Gerir certificados da CA do servidor.
  6. Clique para expandir Gerir certificados.
  7. Clique em Criar novo certificado de AC.

O novo certificado da CA do servidor é apresentado na ranhura Próximo. Se quiser fazer a rotação para o novo certificado da CA do servidor imediatamente, avance com a rotação do certificado da CA do servidor atualizando os clientes e concluindo a rotação.

Para instâncias que usam certificados de servidor emitidos por uma AC partilhada:

  1. Na Google Cloud consola, aceda à página Instâncias do Cloud SQL.

    Aceda a Instâncias do Cloud SQL

  2. Para abrir a página Vista geral de uma instância, clique no nome da instância.
  3. Clique em Associações no menu de navegação do SQL.
  4. Selecione o separador Segurança.
  5. Aceda à secção Gerir certificados do servidor.
  6. Clique para expandir Gerir certificados.
  7. Clique em Criar certificado do servidor.

O novo certificado do servidor é apresentado na posição Próximo. Se quiser usar o novo certificado do servidor imediatamente, avance com a rotação do certificado do servidor atualizando os seus clientes e concluindo a rotação.

gcloud

Para instâncias que usam certificados de servidor autoassinados (CA por instância):

  1. Para obter informações sobre o certificado do servidor, use o comando sql ssl server-ca-certs list:
    gcloud sql ssl server-ca-certs list \
    --instance=INSTANCE_NAME
  2. Para criar um certificado do servidor, use o comando sql ssl server-ca-certs create:
    gcloud sql ssl server-ca-certs create \
    --instance=INSTANCE_NAME
  3. Transfira as informações do certificado para um ficheiro PEM local:
    gcloud sql ssl server-ca-certs list \
    --format="value(cert)" \
    --instance=INSTANCE_NAME > \
    FILE_PATH/FILE_NAME.pem
  4. Atualize todos os seus clientes para usarem as novas informações: copie o ficheiro transferido para os computadores anfitriões dos clientes e substitua os ficheiros server-ca.pem existentes.

Para instâncias que usam certificados de servidor emitidos por uma AC partilhada:

  1. Para obter informações sobre o certificado do servidor, use o comando sql ssl server-certs list:
    gcloud sql ssl server-certs list \
       --instance=INSTANCE_NAME
  2. Para criar um certificado do servidor, use o comando sql ssl server-certs create:
    gcloud sql ssl server-certs create \
       --instance=INSTANCE_NAME
  3. Transfira as informações do certificado para um ficheiro PEM local:
    gcloud sql ssl server-certs list \
       --format="value(ca_cert.cert)" \
       --instance=INSTANCE_NAME > \
       FILE_PATH/FILE_NAME.pem
  4. Atualize todos os seus clientes para usarem as novas informações: copie o ficheiro transferido para os computadores anfitriões dos clientes e substitua os ficheiros server-ca.pem existentes.

Terraform

Para fornecer informações do certificado do servidor como saída, use uma origem de dados do Terraform:

  1. Adicione o seguinte ao ficheiro de configuração do Terraform:
       data "google_sql_ca_certs" "ca_certs" {
         instance = google_sql_database_instance.default.name
       }
    
       locals {
         furthest_expiration_time = reverse(sort([for k, v in data.google_sql_ca_certs.ca_certs.certs : v.expiration_time]))[0]
         latest_ca_cert           = [for v in data.google_sql_ca_certs.ca_certs.certs : v.cert if v.expiration_time == local.furthest_expiration_time]
       }
    
       output "db_latest_ca_cert" {
         description = "Latest CA certificate used by the primary database server"
         value       = local.latest_ca_cert
         sensitive   = true
       }
       
  2. Para criar o ficheiro server-ca.pem, execute o seguinte comando:
       terraform output db_latest_ca_cert > server-ca.pem
       

Certificados de cliente

Crie um novo certificado de cliente

Pode criar até 10 certificados de cliente para cada instância. Para criar certificados de cliente, tem de ter a Cloud SQL Adminfunção do IAM.

Seguem-se alguns aspetos importantes a ter em conta acerca dos certificados de cliente:

  • Se perder a chave privada de um certificado, tem de criar uma nova. Não é possível recuperar a chave privada.
  • Por predefinição, o certificado de cliente tem uma data de validade de 10 anos.
  • Não recebe uma notificação quando os certificados de cliente estão prestes a expirar.
  • A sua instância do Cloud SQL tem de estar em execução para criar um certificado SSL.

Consola

  1. Na Google Cloud consola, aceda à página Instâncias do Cloud SQL.

    Aceda a Instâncias do Cloud SQL

  2. Para abrir a página Vista geral de uma instância, clique no nome da instância.
  3. Clique em Associações no menu de navegação do SQL.
  4. Selecione o separador Segurança.
  5. Clique em Criar certificado de cliente.
  6. Na caixa de diálogo Criar um certificado de cliente, adicione um nome exclusivo.
  7. Clique em Criar.
  8. Na primeira secção da caixa de diálogo New SSL certificate created (Novo certificado SSL criado), clique em Download client-key.pem (Transferir client-key.pem) para transferir a chave privada para um ficheiro denominado client-key.pem.
  9. Na segunda secção, clique em Transferir client-cert.pem para transferir o certificado de cliente para um ficheiro denominado client-cert.pem.
  10. Na terceira secção, clique em Transferir server-ca.pem para transferir o certificado do servidor para um ficheiro denominado server-ca.pem.
  11. Clique em Fechar.

gcloud

  1. Crie um certificado de cliente com o comando ssl client-certs create:

    gcloud sql ssl client-certs create CERT_NAME client-key.pem \
    --instance=INSTANCE_NAME
  2. Obtenha a chave pública do certificado que acabou de criar e copie-a para o ficheiro client-cert.pem com o comando ssl client-certs describe:

    gcloud sql ssl client-certs describe CERT_NAME \
    --instance=INSTANCE_NAME \
    --format="value(cert)" > client-cert.pem
  3. Copie o certificado do servidor para o ficheiro server-ca.pem usando o comando instances describe:

    gcloud sql instances describe INSTANCE_NAME \
    --format="value(serverCaCert.cert)" > server-ca.pem

Terraform

Para criar um certificado de cliente, use um recurso do Terraform:

resource "google_sql_ssl_cert" "postgres_client_cert" {
  common_name = "postgres_common_name"
  instance    = google_sql_database_instance.postgres_instance.name
}

REST v1

  1. Crie um certificado SSL/TLS e atribua-lhe um nome exclusivo para esta instância:

    Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:

    • project-id: o ID do projeto
    • instance-id: o ID da instância
    • client-cert-name: o nome do certificado do cliente

    Método HTTP e URL:

    POST https://sqladmin.googleapis.com/v1/projects/project-id/instances/instance-id/sslCerts

    Corpo JSON do pedido:

    {
      "commonName" : "client-cert-name"
    }
    

    Para enviar o seu pedido, expanda uma destas opções:

    Deve receber uma resposta JSON semelhante à seguinte:

  2. Copie todo o conteúdo do certificado entre as aspas (mas não as aspas) da resposta para ficheiros locais da seguinte forma:
    1. Copie serverCaCert.cert para server-ca.pem.
    2. Copie clientCert.cert para client-cert.pem.
    3. Copie certPrivateKey para client-key.pem.

REST v1beta4

  1. Crie um certificado SSL/TLS e atribua-lhe um nome exclusivo para esta instância:

    Antes de usar qualquer um dos dados do pedido, faça as seguintes substituições:

    • project-id: o ID do projeto
    • instance-id: o ID da instância
    • client-cert-name: o nome do certificado do cliente

    Método HTTP e URL:

    POST https://sqladmin.googleapis.com/sql/v1beta4/projects/project-id/instances/instance-id/sslCerts

    Corpo JSON do pedido:

    {
      "commonName" : "client-cert-name"
    }
    

    Para enviar o seu pedido, expanda uma destas opções:

    Deve receber uma resposta JSON semelhante à seguinte:

  2. Copie todo o conteúdo do certificado entre as aspas (mas não as aspas) da resposta para ficheiros locais da seguinte forma:
    1. Copie serverCaCert.cert para server-ca.pem.
    2. Copie clientCert.cert para client-cert.pem.
    3. Copie certPrivateKey para client-key.pem.

Nesta fase, tem:

  • Um certificado de servidor guardado como server-ca.pem.
  • Um certificado de chave pública do cliente guardado como client-cert.pem.
  • Uma chave privada do cliente guardada como client-key.pem.
Consoante a ferramenta que usa para estabelecer a ligação, estes três itens são especificados de formas diferentes. Por exemplo, quando se liga através do cliente de linha de comandos psql, estes três ficheiros são os valores dos parâmetros sslrootcert, sslcert e sslkey na string de ligação psql. Para ver um exemplo de ligação com o cliente psql e SSL/TLS, consulte o artigo Estabelecer ligação com o cliente psql.

Validação de identidade do servidor

A validação da identidade do servidor depende da configuração da hierarquia da autoridade de certificação (AC) da sua instância do Cloud SQL.

Para instâncias que usam uma CA por instância, a validação da CA também valida a identidade do servidor, uma vez que cada instância tem uma CA exclusiva. Para instâncias que usam uma CA partilhada, a validação do nome do anfitrião, juntamente com a validação da CA, é necessária para a validação da identidade do servidor, uma vez que as CAs do servidor são partilhadas entre instâncias.

Se tiver uma AC por instância, só pode realizar a validação da identidade do servidor baseada no nome DNS para instâncias configuradas com o Private Service Connect. Se tiver uma AC partilhada, pode efetuar a validação da identidade do servidor baseada no nome DNS para todos os tipos de instâncias, nomeadamente Private Service Connect, acesso privado ao serviço e instâncias de IP público.

Se estiver a usar uma AC gerida pelo cliente, pode validar a cadeia de confiança da AC e realizar a validação da identidade do servidor baseada no nome DNS para qualquer tipo de instância que use a AC gerida pelo cliente para o respetivo serverCAmode.

Quando seleciona a opção de AC gerida pelo cliente para a sua instância, pode inserir nomes DNS personalizados no campo SAN do certificado do servidor. Para mais informações, consulte o artigo Edite um campo SAN personalizado.

Pode ver que hierarquia de AC está configurada para uma instância do Cloud SQL através da visualização dos detalhes da instância. Para mais informações, consulte o artigo Veja informações da instância.

Ative a validação da identidade do servidor

Se selecionar a AC partilhada como o modo de AC do servidor da sua instância do Cloud SQL ou se configurar nomes DNS personalizados através de valores SAN personalizados, recomendamos que também ative a validação da identidade do servidor.

As instâncias que usam a AC partilhada como o modo de AC do servidor contêm o nome de DNS da instância no campo Nome alternativo de entidade (SAN) do certificado do servidor. Pode obter este nome DNS através da API de pesquisa de instâncias e usar a resposta como um nome de anfitrião para a validação da identidade do servidor. Tem de configurar a resolução de DNS para o nome DNS.

Para ativar a validação da identidade do servidor para uma instância que usa uma AC partilhada, conclua os seguintes passos:

  1. Recupere o nome DNS.

    1. Para ver informações de resumo sobre uma instância do Cloud SQL, incluindo o nome DNS da instância, use o comando gcloud sql instances describe:

      gcloud sql instances describe INSTANCE_NAME \
        --project=PROJECT_ID

      Faça as seguintes substituições:

      • INSTANCE_NAME: o nome da instância do Cloud SQL
      • PROJECT_ID: o ID ou o número do projeto do projeto Google Cloud que contém a instância
    2. Na resposta, procure o campo dnsNames:. Este campo pode devolver vários nomes DNS, que têm os seguintes formatos:

      Configuração da rede Formato do nome DNS Nível do nome
      Private Service Connect ou endereço IP público INSTANCE_UID.PROJECT_DNS_LABEL.REGION_NAME.sql.goog.

      Exemplo:
      1a23b4cd5e67.1a2b345c6d27.us-central1.sql.goog.
      Instância
      Acesso a serviços privados INSTANCE_UID.PROJECT_DNS_LABEL.REGION_NAME.sql-psa.goog.

      Exemplo:
      1a23b4cd5e67.1a2b345c6d27.us-central1.sql-psa.goog.
      Instância
  2. Crie o registo DNS numa zona DNS. Se estiver a estabelecer ligação de forma privada, então crie o registo DNS numa zona DNS privada na rede da nuvem virtual privada (VPC) correspondente.

  3. Quando se ligar à instância do Cloud SQL para PostgreSQL, configure o nome DNS como o nome do anfitrião. Em seguida, ative a validação da identidade do servidor no cliente.

    Por exemplo, quando usar o cliente psql, especifique a flag sslmode=verify-full. Outros controladores de cliente do PostgreSQL têm flags de configuração semelhantes.

O que se segue?