Casos de uso da segurança do serviço

Este documento descreve casos de uso comuns de segurança do Cloud Service Mesh. Use essas informações para determinar qual modelo de segurança atende melhor às suas necessidades. Este documento também fornece uma visão geral de alto nível do que você precisa configurar para cada caso de uso.

Para uma visão geral da segurança do serviço, consulte Segurança do serviço do Cloud Service Mesh.

Como ativar o TLS mútuo para serviços na malha

Em uma malha de serviço, é possível ativar o TLS mútuo (mTLS, na sigla em inglês) para que o cliente e o servidor em uma comunicação precisem provar as identidades deles e criptografar as comunicações.

Autenticação TLS mútua (mTLS) em uma malha de serviço.
Autenticação TLS mútua (mTLS) em uma malha de serviço (clique para ampliar)

A seção a seguir omite a discussão dos recursos Mesh, Gateway e Route. Esses recursos da API são necessários para criar sua malha e rotear o tráfego, mas você não precisa atualizá-los para ativar o mTLS.

Para conseguir o padrão acima, configure os seguintes recursos da API Compute Engine. Este diagrama usa proxies sidecar, mas a configuração de um aplicativo gRPC sem proxy com mTLS usa os mesmos recursos.

Recursos da API do Compute Engine para mTLS em uma malha.
Recursos da API Compute Engine para mTLS em uma malha (clique para ampliar)

Para criar essa modelo, faça o seguinte:

  1. Crie uma política de Transport Layer Security (TLS) cliente.
  2. Crie uma política de TLS do servidor.
  3. Atualize o campo securitySettings nos serviços de back-end globais existentes para fazer referência à nova política de política de TLS do cliente.

  4. Crie uma política de endpoint:

    1. Faça referência à política de TLS do servidor no campo server_tls_policy.

    2. Defina um EndpointMatcher para selecionar os clientes do Cloud Service Mesh que deve impor a autenticação no tráfego de entrada.

      A seleção de clientes do Cloud Service Mesh é baseada nos rótulos especificados em configuração de inicialização do cliente do Cloud Service Mesh. Esses rótulos podem ser fornecidos manualmente ou preenchidos automaticamente com base nos rótulos fornecidos às implantações do Google Kubernetes Engine.

      No diagrama anterior, os rótulos "mesh-service":"true" são configuradas na política de endpoint e nos clientes do Cloud Service Mesh. É possível escolher quais rótulos são adequados à sua implantação.

    3. Se quiser, defina um TrafficPortSelector que aplique as políticas somente quando as solicitações de entrada forem feitas para a porta especificada na entidade do plano de dados.

O diagrama a seguir mostra os recursos do Compute Engine configurados para mTLS, independentemente de você usar o Envoy ou um aplicativo gRPC sem proxy.

Recursos da API do Compute Engine para mTLS em uma malha.
Recursos da API Compute Engine para mTLS em uma malha (clique para ampliar)

O diagrama a seguir mostra o fluxo de tráfego e lista os recursos da API Compute Engine configurados para ativar o mTLS. O proxy secundário local que fica junto ao pod do GKE do Service B é o endpoint na comunicação.

Recursos da API Compute Engine e fluxo de tráfego para mTLS em uma malha.
Fluxo de recursos e tráfego da API Compute Engine para mTLS em uma malha (clique para ampliar)

A política de endpoint faz o seguinte:

  1. Seleciona um conjunto de endpoints usando um correspondente de endpoints e, opcionalmente, portas nesses endpoints.

    1. A correspondência de endpoint permite especificar regras que determinam se um cliente do Cloud Service Mesh recebe a configuração. Essas regras são baseadas nos metadados xDS que a entidade do plano de dados fornece ao plano de controle. Nesse caso, o Cloud Service Mesh.

      É possível adicionar rótulos ao cliente do Cloud Service Mesh da seguinte maneira:

      • É possível especificar esses metadados manualmente na sua Arquivo de inicialização do cliente do Cloud Service Mesh.

      • Como alternativa, os metadados podem ser preenchidos automaticamente quando você usar o GKE adicionando os pares de chave-valor à seção env dos arquivos demo_server.yaml ou demo_client.yaml. Esses valores são fornecidos no Guia de configuração do Envoy e no Guia de configuração do gRPC sem proxy.

        Por exemplo, somente com o Envoy, você pode prefixar a chave com o prefixo ISTIO_META_. Os nomes das variáveis de ambiente de proxy que começam com ISTIO_META_ são incluídos na inicialização gerada e enviados ao servidor xDS.

        - name: ISTIO_META_app
  value: 'review'
- name: ISTIO_META_version
  value: 'canary'

    2. Se você especificar uma porta, as políticas referenciadas na política do endpoint serão aplicadas somente em solicitações de entrada que especificam a mesma porta. Se você não especificar uma porta, as políticas serão aplicadas em solicitações de entrada que especificam uma porta que também esteja no campo TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, que é fornecido ao cliente do Cloud Service Mesh nas informações de inicialização.

  2. Referencia o TLS do cliente, o TLS do servidor e as políticas de autorização que configuram os endpoints para os quais as solicitações são resolvidas.

A configuração de modos TLS incompatíveis pode resultar em uma interrupção das comunicações. Por exemplo, configurar OPEN no serviço de back-end global ou deixar o campo da política de TLS do cliente em branco e definir MTLS como o valor da política de TLS do servidor na política de endpoint resulta em falha nas tentativas de comunicação. Isso ocorre porque os endpoints configurados para aceitar apenas tentativas de rejeição de mTLS para estabelecer canais de comunicação não autenticados.

Observe a diferença entre uma política TLS de cliente e uma política de TLS do servidor anexada a um serviço de back-end global e uma política de endpoint, respectivamente:

  • A política de TLS do cliente é aplicada ao serviço de back-end global e informa ao proxy Envoy ou ao cliente sem proxy qual modo de TLS, identidade e validação de peering devem ser usados ao abordar o serviço.
  • A política de TLS do servidor é anexada à política do endpoint e indica ao servidor qual modo de TLS, identidade e validação de peering devem ser usados para conexões de entrada.

Como ativar o TLS de um gateway de entrada

Depois de configurar o mTLS para comunicações em malha, proteja o tráfego que entra na malha, conhecido como tráfego de entrada. O Cloud Service Mesh pode configurar seu plano de dados para exigir tráfego de entrada para usar canais de comunicação criptografados por TLS.

Para isso, escolha uma das seguintes opções de arquitetura:

  • Os serviços na malha encerram o TLS do tráfego de um balanceador de carga. Neste modelo, cada serviço da malha é configurado como um back-end na configuração do balanceador de carga; especificamente, no mapa de URLs do balanceador de carga.
  • Um gateway de entrada encerra o TLS do tráfego de um balanceador de carga antes de encaminhá-lo aos serviços na malha. Neste modelo, um serviço dedicado na malha, o gateway de entrada, é configurado como um back-end na configuração do balanceador de carga. Especificamente no URL do balanceador de carga.

As duas opções são explicadas nesta seção.

Os serviços na malha encerram o TLS do tráfego de um balanceador de carga

Se você quiser disponibilizar seus serviços para clientes fora do Google Cloud, use o balanceador de carga de aplicativo externo. Os clientes enviam tráfego ao endereço IP virtual (VIP, na sigla em inglês) Anycast global do balanceador de carga, que encaminha esse tráfego para serviços na malha. Isso significa que há duas conexões quando um cliente externo precisa acessar um serviço na malha.

TLS para um serviço na malha.
TLS para um serviço na malha (clique para ampliar)

O mesmo padrão se aplica quando você usa um balanceador de carga de aplicativo interno. O tráfego de clientes internos chega primeiro ao balanceador de carga, que estabelece uma conexão com o back-end.

Para proteger as duas conexões, faça o seguinte:

  1. Proteja a conexão entre o cliente e o balanceador de carga usando um balanceador de carga de aplicativo externo.
  2. Configure o balanceador de carga para usar os protocolos HTTPS ou HTTP/2 quando ele tentar estabelecer uma conexão com serviços na malha.
  3. Configurar o Cloud Service Mesh para encerrar os clientes HTTPS e apresentar certificados ao cliente, que, nesse caso, é a de carga HTTP(S) externo global.

Para mais informações sobre as etapas 1 e 2, consulte Como configurar um balanceador de carga HTTPS externo multirregional com base em conteúdo.

Ao configurar a segurança do Cloud Service Mesh, você configura vários recursos da API Compute Engine. Esses recursos são separados dos recursos configurados para o balanceador de carga. Você cria um conjunto de Recursos da API Compute Engine (regra de encaminhamento global, proxy de destino, mapa de URLs, e serviços de back-end globais) para o balanceador de carga e configurar Cloud Service Mesh com as APIs de roteamento de serviço. Além disso, no recurso de serviço de back-end, o balanceador de carga tem o esquema de balanceamento de carga INTERNAL_MANAGED, e a Cloud Service Mesh tem o esquema de balanceamento de carga INTERNAL_SELF_MANAGED.

Na etapa 3, você configura o Cloud Service Mesh para que os clientes do Cloud Service Mesh encerrem HTTPS e apresentem certificados aos clientes.

Recursos da API do Compute Engine para TLS funcionar na malha.
Recursos da API do Compute Engine para que o TLS funcione na malha (clique para ampliar)
.

Neste modelo, você realizará as ações a seguir:

  1. Crie um serverTlsPolicy: configure serverCertificate no recurso serverTlsPolicy.
  2. Crie uma política de endpoint:
    1. Faça referência à política de TLS do servidor no campo authentication.
    2. Defina um EndpointMatcher para selecionar as entidades do plano de dados xDS que precisam aplicar autenticação no tráfego de entrada.
    3. Se quiser, defina um TrafficPortSelector que aplique as políticas somente quando as solicitações de entrada forem feitas para a porta especificada no cliente do Cloud Service Mesh.

Como o balanceador de carga de aplicativo externo já está configurado para iniciar Conexões TLS com serviços na sua malha, o Cloud Service Mesh só precisa configure os clientes do Cloud Service Mesh para encerrar conexões TLS.

O gateway de entrada encerra o TLS do tráfego de um balanceador de carga antes de encaminhá-lo aos serviços na malha

Se quiser expor apenas um gateway de entrada para o balanceador de carga, use o padrão de implantação do gateway de entrada. Nesse padrão, o balanceador de carga não aborda diretamente os serviços na malha. Em vez disso, um proxy intermediário na borda da malha e roteia o tráfego para os serviços dentro dela, com base na configuração que recebe do Cloud Service Mesh. O proxy intermediário pode ser um proxy Envoy que você implantou em instâncias de máquina virtual (VM) em um grupo gerenciado de instâncias do Compute Engine.

TLS para um gateway de entrada com mTLS em uma malha.
TLS para um gateway de entrada com mTLS em uma malha (clique para ampliar)

Do ponto de vista da segurança, é possível configurar o gateway de entrada para encerrar o TLS e, opcionalmente, configurar as conexões dentro da malha para que elas sejam protegidas pelo mTLS. Isso inclui conexões entre o gateway de entrada e os serviços na malha e conexões entre os serviços na malha.

Do ponto de vista da configuração, faça o seguinte:

  1. Configure a malha de serviço e ative o mTLS para comunicações dentro da malha (conforme explicado anteriormente).
  2. Configure o balanceador de carga para rotear o tráfego para o gateway de entrada e iniciar conexões usando o protocolo HTTPS (como explicado anteriormente).
  3. Crie um conjunto de recursos da API Compute Engine que represente o gateway de entrada e a política de TLS do servidor.

Na terceira etapa, configure o Cloud Service Mesh para encerrar HTTPS e apresentar certificados da seguinte maneira:

  1. Crie um recurso Mesh para representar a malha.

  2. Crie um recurso Route que aponte para os serviços de back-end globais corretos e anexe o recurso Route ao recurso Mesh.

  3. Crie uma política de TLS para o servidor: configure serverCertificate.

  4. Crie um recurso Gateway para representar o gateway de entrada gerenciado do Cloud Service Mesh.

  5. Anexe o recurso de política de TLS do servidor ao recurso Gateway.

O padrão do gateway de entrada é útil principalmente em grandes organizações que usam VPC compartilhada. Nessa configuração, uma equipe pode permitir apenas o acesso aos serviços por meio de um gateway de entrada. No diagrama anterior, ao configurar a regra de encaminhamento global para o balanceador de carga, forneça um endereço IP diferente (neste exemplo, 10.0.0.2) do fornecido ao configurar a malha (neste exemplo, o endereço da malha é 10.0.0.1). Os clientes que se comunicam por uma entidade do plano de dados xDS configurada pelo Cloud Service Mesh podem usar esse endereço para acessar o gateway de entrada.

Como exemplo, considere o seguinte:

  • Dois projetos de serviço (1 e 2) anexados à mesma rede VPC compartilhada.

  • O projeto de serviço 1 contém uma malha de serviço configurada pelo Cloud Service Mesh.

    O projeto de serviço 1 configurou uma malha e um gateway de entrada. Esse gateway de entrada pode ser acessado no endereço/VIP do 10.0.0.2.

  • O projeto de serviço 2 contém uma malha de serviço configurada pelo Cloud Service Mesh.

    O projeto de serviço 2 pode ou não ter o próprio gateway de entrada.

  • O Cloud Service Mesh configura os clientes do Cloud Service Mesh em cada serviço projeto. Os clientes são inicializados para usar a mesma rede.

Após essa configuração, os clientes na malha do projeto de serviço 2 podem se comunicar com o gateway de entrada no projeto de serviço 1 usando o VIP 10.0.0.2. Isso permite que os proprietários do projeto de serviço 1 configurem roteamento, segurança e outras políticas específicas para o tráfego que entra na malha. Na verdade, os proprietários do projeto de serviço 1 podem informar a outros que os clientes na malha podem alcançar meus serviços no 10.0.0.2.

Limitações

A segurança do serviço do Cloud Service Mesh é compatível apenas com o GKE. Não é possível implantar a segurança do serviço com o Compute Engine.

A seguir