Casos de uso da segurança do serviço

Este documento descreve os casos de uso de segurança do Traffic Director. 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 Traffic Director.

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 da regra de encaminhamento global, do proxy HTTPS de destino e do mapa de URL. Esses recursos da API Compute Engine são necessários para criar sua malha, 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:

Crie uma política de Transport Layer Security (TLS) cliente.
Crie uma política de TLS do servidor.
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.
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 Traffic Director que aplicam a autenticação no tráfego de entrada.
  
  A seleção de clientes do Traffic Director é baseada nos rótulos especificados na configuração de inicialização do cliente do Traffic Director. 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 acima, os rótulos "mesh-service":"true" são configurados na política do endpoint e nos clientes do Traffic Director. É 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.

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:

Seleciona um conjunto de endpoints usando um correspondente de endpoints e, opcionalmente, portas nesses endpoints.
1. O correspondente de endpoints permite especificar regras que determinam se um cliente do Traffic Director 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 Traffic Director.
  
  É possível adicionar rótulos ao cliente do Traffic Director da seguinte forma:
  - É possível especificar esses metadados manualmente no arquivo de inicialização do cliente Traffic Director.
  - 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 Traffic Director nas informações da inicialização.
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 Traffic Director 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 balanceamento de carga HTTP(S) 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 ao uso do balanceamento de carga HTTP(S) 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:

Proteja a conexão entre o cliente e o balanceador de carga usando o balanceamento de carga HTTP(S) externo.
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.
Configure o Traffic Director para que os clientes dele encerrem o HTTPS e apresentem certificados para o cliente, que, neste caso, é o balanceador de carga.

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 Traffic Director, você configura vários recursos da API Compute Engine. Esses recursos são separados dos recursos configurados para o balanceador de carga. Em outras palavras, você cria dois conjuntos de recursos da API Compute Engine (regra de encaminhamento global, proxy de destino, mapa de URL e serviços de back-end globais) com diferentes esquemas de balanceamento de carga:

Um conjunto de recursos configura o balanceador de carga, que tem o esquema de balanceamento de carga INTERNAL_MANAGED.
O outro conjunto de recursos configura o Traffic Director, que tem o esquema de balanceamento de carga INTERNAL_SELF_MANAGED.

Na etapa 3, configure o Traffic Director para que os clientes do Traffic Director 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:

Criar uma política de TLS do servidor: configure terminationTls na transportAuthentication.
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 à porta especificada no cliente do Traffic Director.

Como o balanceamento de carga HTTP(S) externo já está configurado para iniciar conexões TLS com os serviços da malha, o Traffic Director só precisa configurar os clientes do Traffic Director 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 fica na borda da malha e direciona o tráfego para serviços dentro da malha, com base na configuração recebida pelo Traffic Director. 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:

Configure a malha de serviço e ative o mTLS para comunicações dentro da malha (conforme explicado anteriormente).
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).
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 Traffic Director para encerrar HTTPS e apresentar certificados da seguinte maneira:

Crie uma regra de encaminhamento global e um proxy HTTPS de destino para representar o caminho do tráfego de entrada na sua malha.
Anexe o mapa de URLs atual da malha a esse proxy HTTPS de destino. O mapa de URL já contém referências aos vários serviços de back-end globais da sua rede, com base na configuração fornecida quando você configurou a malha e o mTLS.
Crie uma política de TLS para o servidor: configure serverCertificate.
Anexe o recurso de política de TLS do servidor ao proxy HTTPS de destino.

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 acima, ao configurar a regra de encaminhamento global, você fornece um endereço IP diferente (neste exemplo, 10.0.0.2) do que foi fornecido ao configurar a malha (neste exemplo, o endereço da malha é 10.0.0.1). Os clientes que se comunicam por uma entidade de plano de dados xDS configurada pelo Traffic Director 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 Traffic Director.

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 Traffic Director.

O projeto de serviço 2 pode ou não ter o próprio gateway de entrada.
O Traffic Director configura os clientes do Traffic Director em cada projeto de serviço. 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.

A seguir

Para configurar a segurança do serviço do Traffic Director com proxies Envoy, consulte Como configurar a segurança do serviço do Traffic Director com Envoy.
Para configurar a segurança do serviço do Traffic Director com aplicativos gRPC sem proxy, consulte Como configurar a segurança do serviço do Traffic Director com o gRPC sem proxy.