Está a ver a documentação da malha de serviço v1.24.

Versões disponíveis

Cloud Service Mesh
Arquivo 1.24
Arquivo 1.23
Arquivo 1.22
Arquivo 1.21
Arquivo 1.20
Arquivo 1.19
Arquivo 1.18

Esta página foi traduzida pela API Cloud Translation.

Exemplos de utilização da segurança de serviços

Este documento descreve exemplos de utilização comuns de segurança da Cloud Service Mesh. Use estas informações para ajudar a determinar que modelo de segurança se adequa melhor às suas necessidades. Este documento também fornece uma vista geral do que tem de configurar para cada exemplo de utilização.

Para uma vista geral da segurança dos serviços, consulte o artigo Segurança dos serviços da Cloud Service Mesh.

Ativar o TLS mútuo para serviços na malha

Numa malha de serviços, pode ativar o TLS mútuo (mTLS) para que o cliente e o servidor numa comunicação tenham de comprovar as respetivas identidades e encriptar as comunicações.

Autenticação TLS mútua (mTLS) numa malha de serviços. — Autenticação TLS mútua (mTLS) numa malha de serviços (clique para aumentar)

A secção seguinte omite a discussão dos recursos Mesh, Gateway e Route. Estes recursos da API são necessários para criar a sua malha e encaminhar o tráfego, mas não tem de os atualizar para ativar o mTLS.

O padrão anterior pode ser alcançado configurando os seguintes recursos da API Compute Engine. Este diagrama usa proxies sidecar, mas a configuração de uma aplicação gRPC sem proxy com mTLS usa os mesmos recursos.

Recursos da API Compute Engine para mTLS numa malha. — Recursos da API Compute Engine para mTLS numa malha (clique para aumentar)

Para criar este modelo, faça o seguinte:

Crie uma política de segurança da camada de transporte (TLS) do cliente.
Crie uma política de TLS do servidor.
Atualize o campo securitySettings nos seus serviços de back-end globais existentes para referenciar a nova política de TLS do cliente.
Crie uma política de pontos finais:
1. Faça referência à política TLS do servidor no campo server_tls_policy.
2. Defina um EndpointMatcher para selecionar os clientes do Cloud Service Mesh que devem aplicar a autenticação no tráfego de entrada.
  
  A seleção de clientes do Cloud Service Mesh baseia-se nas etiquetas especificadas na configuração de arranque do cliente do Cloud Service Mesh. Estas etiquetas podem ser fornecidas manualmente ou preenchidas automaticamente com base nas etiquetas fornecidas às suas implementações do Google Kubernetes Engine (GKE).
  
  No diagrama anterior, as etiquetas "mesh-service":"true" são configuradas na política de ponto final e nos clientes da Cloud Service Mesh. Pode escolher etiquetas adequadas à sua implementação.
3. Opcionalmente, defina um TrafficPortSelector que aplique as políticas apenas quando forem feitos pedidos de entrada à porta especificada na entidade do plano de dados.

O diagrama seguinte mostra os recursos do Motor de Cálculo que configura para o mTLS, independentemente de usar o Envoy ou uma aplicação gRPC sem proxy.

O diagrama seguinte mostra o fluxo de tráfego e lista os recursos da API Compute Engine que configura para ativar o mTLS. O proxy sidecar local que se encontra junto ao pod do GKE do serviço B é o ponto final na comunicação.

Recursos da API Compute Engine e fluxo de tráfego para mTLS numa malha. — Recursos da API Compute Engine e fluxo de tráfego para mTLS numa malha (clique para aumentar)

A política de pontos finais faz o seguinte:

Seleciona um conjunto de pontos finais através de um motor de correspondência de pontos finais e, opcionalmente, portas nesses pontos finais.
1. A correspondência de pontos finais permite especificar regras que determinam se um cliente da Cloud Service Mesh recebe a configuração. Estas regras baseiam-se nos metadados xDS que a entidade do plano de dados fornece ao plano de controlo, neste caso, o Cloud Service Mesh.
  
  Pode adicionar etiquetas ao cliente do Cloud Service Mesh da seguinte forma:
  - Pode especificar manualmente estes metadados no ficheiro de arranque do cliente do Cloud Service Mesh.
  - Em alternativa, os metadados podem ser preenchidos automaticamente quando usa o GKE adicionando os pares de chave-valor à secção env dos ficheiros demo_server.yaml ou demo_client.yaml. Estes valores são fornecidos no guia de configuração do Envoy e no guia de configuração do gRPC sem proxy.
    
    Por exemplo, apenas com o Envoy, pode adicionar o prefixo ISTIO_META_ à chave. Os nomes das variáveis de ambiente do proxy que começam com ISTIO_META_ são incluídos no arranque gerado e enviados para o servidor xDS.
```
- name: ISTIO_META_app
  value: 'review'
- name: ISTIO_META_version
  value: 'canary'
```
2. Se especificar uma porta, as políticas referenciadas na política de ponto final só são aplicadas a pedidos de entrada que especifiquem a mesma porta. Se não especificar uma porta, as políticas são aplicadas a pedidos de entrada que especifiquem uma porta que também esteja no campo TRAFFICDIRECTOR_INBOUND_BACKEND_PORTS, que é fornecido ao cliente do Cloud Service Mesh nas respetivas informações de arranque.
Faz referência ao TLS do cliente, ao TLS do servidor e às políticas de autorização que configuram os pontos finais para os quais os pedidos são resolvidos.

A configuração de modos TLS incompatíveis pode resultar numa interrupção das comunicações. Por exemplo, definir OPEN no serviço de back-end global ou deixar o campo da política TLS do cliente vazio e definir MTLS como o valor da política TLS do servidor na política de ponto final resulta em tentativas de comunicação falhadas. Isto deve-se ao facto de os pontos finais configurados para aceitar apenas mTLS rejeitarem tentativas de estabelecer canais de comunicação não autenticados.

Tenha em atenção a distinção entre uma política TLS do cliente e uma política TLS do servidor anexadas a um serviço de back-end global e a uma política de ponto final, respetivamente:

A política de TLS do cliente é aplicada ao serviço de back-end global. Indica ao proxy Envoy ou ao cliente sem proxy que modo TLS, identidade e abordagem de validação de pares usar ao aceder ao serviço.
A política TLS do servidor está anexada à política de ponto final. Indica ao servidor que modo TLS, identidade e abordagem de validação de pares usar para ligações recebidas.

Ativar TLS para um gateway de entrada

Depois de configurar o mTLS para comunicações na malha, pode querer proteger o tráfego que está a entrar na sua malha, conhecido como tráfego de entrada. O Cloud Service Mesh pode configurar o seu plano de dados para exigir que o tráfego de entrada use canais de comunicação encriptados com TLS.

Para atingir este objetivo, escolha uma das seguintes opções de arquitetura:

Os serviços na malha terminam o TLS para o tráfego de um balanceador de carga. Neste modelo, cada serviço na 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 termina o TLS para o tráfego de um balanceador de carga antes de encaminhar o tráfego para os 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 equilibrador de carga, especificamente, no mapa de URLs do equilibrador de carga.

Ambas as opções são explicadas nesta secção.

Os serviços na malha terminam o TLS para o tráfego de um balanceador de carga

Se quiser disponibilizar os seus serviços a clientes fora de Google Cloud, pode usar um Application Load Balancer externo. Os clientes enviam tráfego para o endereço IP virtual (VIP) Anycast global do balanceador de carga, que, em seguida, encaminha esse tráfego para os serviços na sua malha. Isto significa que existem duas ligações quando um cliente externo precisa de aceder a um serviço na malha.

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

O mesmo padrão aplica-se quando usa um equilibrador de carga de aplicações interno. O tráfego de clientes internos chega primeiro ao equilibrador de carga, que, em seguida, estabelece uma ligação ao back-end.

Para proteger ambas as ligações, faça o seguinte:

Proteja a ligação entre o cliente e o balanceador de carga através de um balanceador de carga de aplicações externo.
Configure o balanceador de carga para usar os protocolos HTTPS ou HTTP/2 quando tentar estabelecer uma ligação com os serviços na malha.
Configure a malha de serviços do Google Cloud para que os clientes da malha de serviços do Google Cloud terminem o HTTPS e apresentem certificados ao cliente, que, neste caso, é o equilibrador de carga.

Para mais informações sobre os passos 1 e 2, consulte o artigo Configurar um balanceador de carga HTTPS externo baseado em conteúdo e com várias regiões.

Quando configura a segurança da Cloud Service Mesh, configura vários recursos da API Compute Engine. Estes recursos estão separados dos recursos que configura para o equilibrador de carga. 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 equilibrador de carga e configura a Cloud Service Mesh com as APIs de encaminhamento de serviços. 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 o Cloud Service Mesh tem o esquema de balanceamento de carga INTERNAL_SELF_MANAGED.

No passo 3, configura o Cloud Service Mesh para que os clientes do Cloud Service Mesh terminem o HTTPS e apresentem certificados aos clientes.

Recursos da API Compute Engine para TLS para serviço na malha. — Recursos da API Compute Engine para TLS para serviço em malha (clique para aumentar)

Neste modelo, faz o seguinte:

Crie um serverTlsPolicy: configure serverCertificate no recurso serverTlsPolicy.
Crie uma política de pontos finais:
1. Faça referência à política TLS do servidor no campo authentication.
2. Defina um EndpointMatcher para selecionar as entidades do plano de dados xDS que devem aplicar a autenticação no tráfego de entrada.
3. Opcionalmente, defina um TrafficPortSelector que aplique as políticas apenas quando forem feitos pedidos de entrada à porta especificada no cliente da malha de serviços na nuvem.

Uma vez que o Application Load Balancer externo já está configurado para iniciar ligações TLS aos serviços na sua malha, o Cloud Service Mesh só precisa de configurar os clientes do Cloud Service Mesh para terminar as ligações TLS.

O gateway de entrada termina o TLS para o tráfego de um balanceador de carga antes de encaminhar o tráfego para os serviços na malha

Se quiser expor apenas um gateway de entrada ao seu equilibrador de carga, pode usar o padrão de implementação do gateway de entrada. Neste padrão, o equilibrador de carga não se dirige diretamente aos serviços na sua malha. Em alternativa, um proxy intermédio está localizado no limite da sua malha e encaminha o tráfego para os serviços no interior da malha, com base na configuração que recebe da Cloud Service Mesh. O proxy intermédio pode ser um proxy Envoy implementado em instâncias de máquinas virtuais (VMs) num grupo de instâncias geridas do Compute Engine.

TLS para um gateway de entrada com mTLS numa malha. — TLS para um gateway de entrada com mTLS numa malha (clique para aumentar)

Do ponto de vista da segurança, configura o gateway de entrada para terminar o TLS e, em seguida, configura opcionalmente as ligações na sua malha para que fiquem protegidas pelo mTLS. Estas incluem ligações entre o gateway de entrada e os seus serviços na malha, bem como ligações entre os seus serviços na malha.

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

Configure a malha de serviços e ative o mTLS para comunicações na malha (conforme explicado anteriormente).
Configure o balanceador de carga para encaminhar o tráfego para o gateway de entrada e iniciar ligações através do protocolo HTTPS (conforme explicado anteriormente).
Crie um conjunto de recursos da API Compute Engine que representam o gateway de entrada e a respetiva política TLS do servidor.

Para o terceiro passo, configure a malha de serviços na nuvem para terminar o HTTPS e apresentar certificados da seguinte forma:

Crie um recurso Mesh para representar a malha.
Crie um recurso Route que aponte para os serviços de back-end globais corretos e anexe o recurso Route ao recurso Mesh.
Crie uma política TLS do servidor: configure serverCertificate.
Crie um recurso Gateway para representar o gateway de entrada gerido do Cloud Service Mesh.
Anexe o recurso de política de TLS do servidor ao recurso Gateway.

O padrão de gateway de entrada é especialmente útil em grandes organizações que usam a VPC partilhada. Nessa definição, uma equipa pode apenas permitir o acesso aos respetivos serviços através de um gateway de entrada. No diagrama anterior, quando configura a regra de encaminhamento global para o equilibrador de carga, fornece um endereço IP diferente (neste exemplo, 10.0.0.2) do fornecido quando configura a malha (neste exemplo, o endereço da malha é 10.0.0.1). Os clientes que comunicam através de uma entidade do plano de dados xDS configurada com a Cloud Service Mesh podem usar este endereço para aceder ao gateway de entrada.

Por exemplo, suponha o seguinte:

Dois projetos de serviço (1 e 2), ambos anexados à mesma rede de VPC partilhada.
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. Este gateway de entrada é acessível no endereço/VIP 10.0.0.2.
O projeto de serviço 2 contém uma malha de serviços configurada pelo Cloud Service Mesh.

O projeto de serviço 2 pode ou não ter a sua própria gateway de entrada.
O Cloud Service Mesh configura os clientes do Cloud Service Mesh em cada projeto de serviço. Os clientes são inicializados para usar a mesma rede.

Dada esta configuração, os clientes na malha do projeto de serviço 2 podem comunicar com o gateway de entrada no projeto de serviço 1 através do 10.0.0.2 VIP. Isto permite aos proprietários do projeto de serviço 1 configurar o encaminhamento, a segurança e outras políticas específicas do tráfego que entra na malha. Na prática, os proprietários do projeto de serviço 1 podem dizer a outros que os clientes na sua malha podem alcançar os meus serviços em 10.0.0.2.

Limitações

A segurança do serviço Cloud Service Mesh só é suportada com o GKE. Não pode implementar a segurança de serviços com o Compute Engine.

O que se segue?

Para configurar a segurança do serviço do Cloud Service Mesh com proxies Envoy, consulte o artigo Configurar a segurança do serviço do Cloud Service Mesh com o Envoy.
Para configurar a segurança do serviço Cloud Service Mesh com aplicações gRPC sem proxy, consulte o artigo Configurar a segurança do serviço Cloud Service Mesh com gRPC sem proxy.