CA do servidor SSL do Google Cloud rotacione

1

O Google Cloud Console está solicitando a expiração iminente do certificado em uma instância do Google Cloud SQL.

Temos vários serviços que se conectam a essa instância de banco de dados:

  • Compute Engine (por meio do Cloud SQL Proxy - cloud_sql_proxy_x64 )
  • AppEngine
  • Desktop (via Cloud SQL Proxy - cloud_sql_proxy_x64 )

Perguntas

  • Quando girarmos o certificado, tudo precisará ser reinicializado para obter a nova conexão? Ou os serviços apenas usarão o novo certificado quando necessário?

  • As instâncias do Compute Engine perdem a conexão com o servidor SQL?

  • Precisarei excluir as instâncias do AppEngine para forçá-las a se reconectar ou elas continuarão?

Estamos tentando evitar o tempo de inatividade durante este trabalho. Sua percepção é apreciada.

Isso é o que está sendo exibido no painel do Cloud SQL:

    
por Carl Smith 17.09.2018 / 17:41

1 resposta

1

Resposta curta : nas implantações atuais que usam o Cloud SQL Proxy e os serviços gerenciados no App Engine, você deve conseguir fazer essa alteração sem incorrer em tempo de inatividade .

Recomendo a revisão da documentação do Cloud SQL na rotação do certificado (esse documento é relevante para MySQL; há um documento semelhante para o PostgreSQL . Há alguns pontos de nota dos documentos:

  • A configuração explícita de SSL / TLS é apenas necessária quando você se conecta à instância diretamente, usando seu endereço IP:

    SSL/TLS is needed to provide security when you connect to Cloud SQL using IP addresses.

    Quando você emprega o componente Cloud SQL Proxy, isso lida com o encapsulamento e a proteção da conexão com a instância do banco de dados em seu nome. Isso inclui o outro benefício principal do Cloud SQL Proxy: não há necessidade de colocar os IPs dos hosts conectados de forma explícita na lista de permissões, o que pode ser impossível em uma configuração de nuvem em que os hosts são de curta duração com endereços IP efêmeros.

  • O Cloud SQL usa certificados TLS autoassinados:

    Cloud SQL uses a self-signed, per-instance server certificate

    Isso é importante para qualquer aplicativo que se conecte diretamente usando o endereço IP. Para garantir que eles estejam conversando com o legítimo host do Cloud SQL, esses aplicativos devem ser configurados para verificar o certificado do servidor na conexão inicial. Como o certificado é auto-assinado, eles só podem fazê-lo se tiverem uma cópia local do certificado para comparação.

    Esse é o motivo do processo de atualização em várias etapas. Você tem a oportunidade de baixar o novo certificado e configurar seus aplicativos para aceitar o antigo e o novo antes de ativá-lo no seu host.

O arquivo baixado com o novo certificado do servidor contém o certificado atual e o próximo (novo), portanto, isso é compatível para conexões feitas à instância, independentemente de qual versão do certificado é "atual" no servidor no ponto de conexão. O requisito mais importante é que você não torne o "próximo" certificado "atual" até que todos os clientes downstream que se conectam via IP tenham recebido o novo arquivo de certificado, pois não verificarão a autenticidade do servidor.

    
por 17.09.2018 / 20:32