Práticas recomendadas para usar gateways de saída do Cloud Service Mesh em clusters do GKE

Neste documento, descrevemos como usar o Cloud Service Mesh gateways de saída e outros controles do Google Cloud para proteger o tráfego de saída (saída) de cargas de trabalho implantadas em um cluster do Google Kubernetes Engine (GKE). Esses controles podem limitar conexões a serviços externos com base na identidade do aplicativo de origem, no namespace de uma equipe, no domínio de destino e em outras propriedades das solicitações de saída.

O público-alvo deste documento inclui engenheiros de rede, plataforma e segurança que administram os clusters do GKE usados por uma ou mais equipes de entrega de software. Os controles descritos aqui podem ser especialmente úteis para organizações que precisam demonstrar conformidade com as regulamentações (por exemplo, o GDPR e o PCI).

Introdução

A abordagem tradicional para a segurança de rede foi definir os perímetros de segurança em torno de um grupo de aplicativos. Os firewalls são usados nesses perímetros para permitir ou negar o tráfego com base em endereços IP de origem e destino, enquanto confia em aplicativos e tráfego contidos nele. No entanto, essa confiança envolve risco. Uma pessoa mal-intencionada com informações privilegiadas, ou alguém que comprometa o perímetro, pode se mover livremente dentro da rede, acessar e extrair dados, atacar sistemas de terceiros e interferir nos sistemas de administração.

Quando as cargas de trabalho em execução em um cluster do Kubernetes fazem conexões de saída com os hosts na Internet, a aplicação dos controles de segurança tradicionais baseados em IP pode ser complicada porque:

• Os endereços IP do pod não representam adequadamente a identidade da carga de trabalho que faz a conexão. Em um ambiente do Kubernetes, os endereços IP do pod são atribuídos efêmeros e são reciclados frequentemente à medida que os pods entram.

• Geralmente, não é possível identificar um conjunto de endereços IP pequeno e fixo para determinados hosts de destino. Os endereços IP mudam com frequência. Variam por região e podem ser retirados de grandes intervalos ou representando caches, proxies ou CDNs.

• Várias equipes que compartilham o mesmo cluster multilocatário, com um intervalo compartilhado de IPs de origem, podem ter requisitos de conectividade externa diferentes.

O Cloud Service Mesh é uma malha de serviço totalmente gerenciada no Google Cloud com base na malha de serviço Istio de código aberto. Uma malha de serviço é uma maneira uniforme de conectar, gerenciar e proteger a comunicação com aplicativos. As malhas de serviço adotam uma abordagem voltada ao aplicativo e usam identidades confiáveis, em vez de uma abordagem voltada ao IP da rede.

É possível implantar uma malha de serviço de maneira transparente, sem a necessidade de modificar o código do aplicativo atual. O uso de uma malha de serviço ajuda a fazer a separação entre o trabalho de equipes de desenvolvimento responsáveis por fornecer e liberar recursos de aplicativos e dos administradores de rede ao fornecer controle declarativo do comportamento da rede.

O Cloud Service Mesh oferece a opção de implantar proxies de encaminhamento autônomos,conhecidos como gateways de saída, na borda da malha. Neste guia, explicamos como os recursos do proxy do gateway de saída podem ser combinados com os recursos do Google Cloud para controlar, autorizar e observar o tráfego de saída nas cargas de trabalho implantadas em um cluster do GKE.

Arquitetura de defesa em profundidade

O diagrama abaixo mostra uma arquitetura que adota uma abordagem de defesa profunda para o controle refinado do tráfego de saída para um cluster usado por várias equipes. Os controles são baseados Camada 4 (transporte) e Camada 7 (aplicativo) controles de rede.

A arquitetura usa os seguintes recursos e controles:

• Um cluster particular do GKE: por padrão, os nós em um cluster específico do GKE têm apenas endereços IP internos e não são conectados à Internet.

• Cloud NAT: o Cloud NAT permite acesso à Internet de saída pelo cluster privado.

• Regras de firewall de nuvem privada virtual (VPC): configure as regras de firewall da VPC para aplicar controles de Camada 4 (transporte) a conexões de/para nós do cluster do GKE. É possível aplicar regras de firewall da VPC a VMs com base em contas de serviço ou tags de rede.

• Pools de nós do GKE com diferentes contas de serviço. Isso permite que você configure diferentes regras de firewall a serem aplicadas, dependendo do pool de nós a que um nó pertence.

• Namespacesdo Kubernetes: você cria namespaces para cada equipe para fornecer controle de administração e isolamento. Os administradores de rede usam um namespace dedicado para implantar o gateway de saída e configurar o roteamento em hosts externos.

• Políticas de rede do Kubernetes: é possível aplicar os controles da Camada 4 aos pods com as políticas de rede. Cada política de rede tem um escopo para um namespace e pode ser escopo mais refinada a pods específicos em um namespace.

• Um gateway de saída: o tráfego que sai de pods dentro da malha é direcionado por proxies de gateway de saída dedicados em execução em nós dedicados. Você implanta os gateways de saída com um escalonador automático horizontal de pods Assim, o número de réplicas aumenta e diminui com o tráfego.

• Políticas de autorização: use políticas de autorização de malha para aplicar controles de Camada 7 (aplicativo) ao tráfego entre pods dentro da malha e para o tráfego que sai da malha.

• Recursos do arquivo secundário: você usa os recursos do arquivo secundário para controlar o escopo de configuração dos proxies sidecar em execução em cada pod de carga de trabalho. É possível usar o recurso sidecar para configurar os namespaces, os pods e os serviços externos visíveis para uma carga de trabalho.

• Acesso privado do Google: com essa opção, os nós e os pods no cluster privado podem acessar as APIs do Google e extrair imagens do Docker do Container Registry.

• Identidade da carga de trabalho do GKE: com a identidade da carga de trabalho, é possível usar o Gerenciamento de identidade e acesso (IAM) para conceder permissões de API a cargas de trabalho específicas seguindo o princípio do menor privilégio, sem a necessidade de lidar com secrets.

Como configurar controles de saída

Se você usa o gateway de saída para proteger o tráfego de saída da malha, recomendamos que configure os controles de defesa d'água descritos nesta seção.

Usar o GKE particular com o Cloud NAT

Quando a segurança é importante, o primeiro requisito de muitas organizações é evitar a atribuição de endereços IP públicos às cargas de trabalho. Um cluster particular do GKE atende a esse requisito. É possível configurar o modo Nativo de VPC no cluster particular para que os pods e serviços recebam endereços IP de intervalos secundários na VPC. Os endereços IP de pods nativos de VPC podem ser roteados nativamente na rede VPC.

Algumas cargas de trabalho podem exigir acesso a serviços fora da rede VPC e à Internet. Permitir que cargas de trabalho se conectem a hosts externos sem precisar que tenham endereços IP públicos, configure Cloud NAT para fornecer conversão de endereços de rede (NAT).

Certifique-se de que o Cloud NAT esteja configurado para que o gateway de saída possa criar um número suficiente de conexões simultâneas para destinos externos. Para evitar o esgotamento da porta e problemas com atrasos de reutilização de conexão, defina o número mínimo de portas por VM adequadamente. Consulte a Visão geral de endereço e porta do Cloud NAT para mais detalhes. Aumentar o número de réplicas do gateway de saída pode ajudar a reduzir as chances de conflitos de mapeamento independentes de endpoint.

Configurar o Acesso privado do Google para APIs e serviços do Google

É provável que suas cargas de trabalho tenham acesso às APIs e aos serviços do Google. Use o Acesso privado do Google com zonas DNS personalizadas para permitir a conectividade de sub-redes VPC particulares para APIs do Google usando um conjunto de quatro endereços IP. Ao usar esses endereços IP, não é necessário que os pods tenham endereços IP externos e o tráfego nunca saia da rede do Google. É possível usar private.googleapis.com (199.36.153.8/30) ou restricted.googleapis.com (199.36.153.4/30), dependendo do uso do VPC Service Controls.

Use a Identidade da carga de trabalho e o IAM para proteger ainda mais as APIs e os serviços do Google

Usar a Identidade da carga de trabalho é a maneira recomendada para permitir que as cargas de trabalho do GKE sejam autenticadas com as APIs do Google e com os administradores para aplicar controles de autorização de "privilégio mínimo" usando o IAM.

Ao usar o Acesso privado do Google, a Identidade da carga de trabalho e o IAM, você permite que os pods de carga de trabalho ignorem com segurança o gateway de saída e se conectem diretamente às APIs e aos serviços do Google.

Usar namespaces do Kubernetes para controle administrativo

Os namespaces são um recurso organizacional útil em ambientes com muitos usuários, equipes ou locatários. Elas podem ser consideradas como um cluster virtual e permitem que a responsabilidade administrativa de grupos de recursos do Kubernetes seja delegada a diferentes administradores.

Os namespaces são um recurso importante para o isolamento do controle administrativo. No entanto, eles não fornecem, por padrão, isolamento de nó, isolamento de plano de dados ou rede.

O Cloud Service Mesh cria com base em namespaces do Kubernetes usando-os como um unidade de locação em uma malha de serviço. As políticas de autorização de malha e os recursos sidecar podem restringir a visibilidade e o acesso com base nos atributos de namespace, identidade e Camada 7 (aplicativo) do tráfego de rede.

Da mesma forma, você pode usar as políticas de rede do Kubernetes para permitir ou negar conexões de rede na Camada 4 (transporte).

Execute gateways de saída em nós de gateway dedicados

A execução de gateways de saída em nós em um pool de nós de gateway dedicado oferece várias vantagens. Os nós externos podem usar uma configuração reforçada, e é possível configurar regras de firewall da VPC para impedir que as cargas de trabalho alcancem hosts externos diretamente. Os pools de nós podem ser escalonados de modo independente usando o autoescalador do cluster.

Para permitir um controle administrativo separado do gateway de saída, implante-o em um namespace istio-egress dedicado. No entanto, os namespaces são um recurso em todo o cluster. Portanto, não é possível usá-los para controlar em quais nós a implantação é executada. Para controle de implantação, use um seletor de nós para a implantação do gateway de saída. Assim, ela será executada em nós rotulados como membros do pool de nós de gateway.

Garanta que apenas pods de gateway possam ser executados nos nós de gateway. Outros pods precisam ser instruídos a partir dos nós do gateway. Caso contrário, os controles de saída podem ser ignorados. É possível impedir a execução das cargas de trabalho em determinados nós usando taints e tolerâncias. Mantenha os nós no pool e adicione uma tolerância correspondente à implantação do gateway de saída.

Importante: restrinja a tolerância da implantação do gateway de saída para que as cargas de trabalho não possam ser implantadas nos nós de gateway. As opções para restringir o uso de tolerâncias são descritas mais adiante neste guia.

Aplicar regras de firewall VPC a nós específicos

Configure o roteamento da malha de serviço para direcionar o tráfego de saída das cargas de trabalho em execução no pool de nós padrão por meio dos gateways de saída em execução no pool de nós de gateway. No entanto, a configuração de roteamento da malha não precisa ser considerada como um limite de segurança, porque há várias maneiras de uma carga de trabalho ignorar os proxies da malha.

Para impedir que as cargas de trabalho de aplicativos se conectem diretamente a hosts externos, aplique regras de firewall de saída restritivas aos nós do pool de nós padrão. Aplique regras de firewall separadas aos nós do gateway para que os pods do gateway de saída em execução possam se conectar a hosts externos.

Ao criar uma regra de firewall da VPC, especifique as portas e protocolos permitidos e negando a direção do tráfego a ela. As regras de saída se aplicam ao tráfego de saída e as regras de entrada se aplicam ao tráfego de entrada. O padrão para a saída é allow, e o padrão para entrada é deny.

As regras de firewall são aplicadas em ordem com base em um número de prioridade especificado por você. As regras de firewall são com estado, o que significa que se o tráfego específico de uma VM for permitido, ele também retornará o tráfego usando a mesma conexão.

O diagrama a seguir mostra como regras de firewall separadas podem ser aplicadas a nós em dois pools de nós diferentes com base na conta de serviço atribuída a um nó. Nesse caso, uma regra de firewall deny all padrão nega o acesso de saída para toda a VPC. Para evitar a substituição de regras de firewall padrão essenciais para seu cluster operar, a regra deny all precisa usar uma prioridade baixa, como 65535. Uma regra de firewall de saída aditiva e de maior prioridade é aplicada aos nós de gateway para permitir que eles se conectem diretamente a hosts externos nas portas 80 e 443. O pool de nós padrão não tem acesso a hosts externos.

Usar políticas de rede do Kubernetes como firewall para pods e namespaces

Use políticas de rede do Kubernetes para aplicar uma camada extra de segurança como parte de uma estratégia de defesa profunda. As políticas de rede têm escopo de namespace e operam na Camada 4 (transporte). As políticas de rede permite restringir a entrada e a saída nos seguintes casos:

• Entre namespaces
• Pods em um namespace
• Para portas e blocos de IP específicos.

Depois que qualquer política de rede seleciona pods em um namespace, as conexões que não são explicitamente permitidas são rejeitadas. Quando várias políticas de rede são aplicadas, o resultado é aditivo e é uma união das políticas. A ordem de aplicação das políticas não importa.

Confira alguns exemplos de políticas de rede:

• Permita conexões de saída dos namespaces da carga de trabalho para os namespaces istio-system e istio-egress. Os pods precisam conseguir se conectar plano de controle e o gateway de saída.
• Permitir que cargas de trabalho façam consultas DNS dos namespaces da carga de trabalho para a porta 53 no namespace kube-system.
• Como alternativa, permita que as cargas de trabalho no mesmo namespace se conectem umas às outras.
• Ou então, permita conexões de saída entre os namespaces usados por equipes de aplicativos diferentes.
• Permitir conexões de saída de namespaces de carga de trabalho para os VIPs das APIs do Google (expostas usando o acesso privado do Google). O Cloud Service Mesh fornece uma AC gerenciada e a expõe como uma API. Portanto, os proxies secundários precisam ser capazes de se conectar a ela. Também é provável que algumas cargas de trabalho precisem de acesso às APIs do Google.
• Permitir conexões de saída de namespaces de carga de trabalho para o servidor de metadados do GKE para que os proxies sidecar e as cargas de trabalho possam fazer consultas de metadados e autenticar nas APIs do Google.

Por padrão, quando um proxy sidecar é injetado em um pod de carga de trabalho, as regras iptables são programadas para que o proxy capture todo o tráfego TCP de entrada e saída. No entanto, como mencionado anteriormente, há maneiras de as cargas de trabalho ignorarem o proxy. As regras de firewall da VPC impedem o acesso direto de saída dos nós padrão que executam as cargas de trabalho. Use as políticas de rede do Kubernetes para garantir que nenhuma saída externa direta seja possível dos namespaces da carga de trabalho e que a saída seja possível para o namespace istio-egress.

Se você também controlar a entrada com as políticas de rede, precisará criar políticas de entrada de acordo com as políticas de saída.

Configuração e segurança do Service Mesh

As cargas de trabalho em execução em uma malha de serviço não são identificadas com base nos endereços IP. O Cloud Service Mesh atribui uma identidade forte e verificável à de um certificado X.509 e para cada carga de trabalho. A comunicação confiável entre cargas de trabalho é estabelecida com conexões TLS mútuas (mTLS) autenticadas e criptografadas.

O uso da autenticação mTLS com uma identidade bem definida para cada aplicativo permite o uso de políticas de autorização de malha para um controle refinado sobre como as cargas de trabalho podem se comunicar com serviços externos.

Embora o tráfego possa sair da malha diretamente dos proxies sidecar, caso precise de mais controle, recomendamos que você encaminhe o tráfego por meio dos gateways de saída, conforme descrito neste guia.

Gerenciar a configuração dos controles de saída em um namespace dedicado

Permita que os administradores de rede gerenciem centralmente os controles usando um namespace istio-egress dedicado para a configuração da malha relacionada à saída. Conforme recomendado anteriormente, implante o gateway de saída no namespace istio-egress. É possível criar e gerenciar entradas de serviço, gateways e políticas de autorização nesse namespace.

Importante :para configurar o plano de controle e os gateways da malha, o O instalador do Cloud Service Mesh cria um ConfigMap do Kubernetes no namespace istio-system. Se instalar um gateway em um namespace diferente, você será responsável por copiar o ConfigMap para esse namespace e por manter as configurações nele ao fazer upgrade. Uma versão futura do Cloud Service Mesh vai gerenciar a configuração do gateway automaticamente.

Solicitar configuração explícita de destinos externos

Certifique-se de que os proxies de malha só sejam programados com rotas para hosts externos definidos explicitamente no registro de malha de serviço. Defina o modo de política de tráfego de saída como REGISTRY_ONLY em um padrão recurso de arquivo secundário para cada namespace. Definir a política de tráfego de saída da malha não deve ser considerado, por si só, um controle de perímetro seguro.

Definir destinos externos com entradas de serviço

Configurar Entradas de serviço para registrar explicitamente hosts externos no registro de serviço da malha. Por padrão, as entradas de serviço ficam visíveis para todos os namespaces. Use o Atributo exportTo para controlar em quais namespaces uma entrada de serviço fica visível. As entradas de serviço determinam as rotas de saída configuradas em proxies de malha. No entanto, elas não precisam ser consideradas por si mesmos para determinar a quais cargas de trabalho de hosts externos podem se conectar.

Configurar o comportamento do gateway de saída com o recurso de gateway

Configure o comportamento de balanceamento de carga dos gateways de saída usando o Gateway recurso. O balanceador de carga pode ser configurado para um determinado conjunto de hosts, protocolos e portas e associado a uma implantação de gateway de saída. Por exemplo, um gateway pode ser configurado para saída nas portas 80 e 443 para qualquer host externo.

No Cloud Service Mesh, o mTLS automático é ativado por padrão. Com o mTLS automático, um proxy sidecar do cliente detecta automaticamente se o servidor tem um sidecar. O sidecar do cliente envia o mTLS para as cargas de trabalho que têm sidecars e um tráfego de texto simples para as que não têm. Mesmo com o mTLS automático, o tráfego enviado para o gateway de saída de proxies sidecar não usa automaticamente o mTLS. Para indicar como as conexões com o gateway de saída devem ser protegidas, defina o modo TLS no recurso Gateway. Sempre que possível, use mTLS para conexões de proxies sidecar ao gateway de saída.

É possível permitir que as cargas de trabalho iniciem conexões TLS (HTTPS). Se as cargas de trabalho originarem conexões TLS, geralmente na porta 443, você precisa configurar o gateway para usar o modo passthrough para conexões nessa porta. No entanto, usar o modo passthrough significa que o gateway não pode aplicar políticas de autorização com base na identidade da carga de trabalho ou nas propriedades da solicitação criptografada. Além disso, não é possível usar o mTLS e o passthrough juntos no momento.

Configurar serviços virtuais e regras de destino para rotear o tráfego por meio do gateway

Use serviços virtuais e regras de destino para configurar o roteamento de tráfego de proxies sidecar pelo gateway de saída para destinos externos. Os serviços virtuais definem regras para corresponder a determinado tráfego. O tráfego correspondente é enviado para um destino. As regras de destino podem definir subconjuntos (por exemplo, o gateway de saída ou um host externo) e como o tráfego precisa ser manipulado ao ser roteado para o destino.

Use uma única regra de destino para vários hosts de destino a fim de especificar explicitamente como o tráfego de proxies de arquivo secundário para o gateway precisa ser protegido. Como explicado anteriormente, o método preferencial é que as cargas de trabalho enviem solicitações de texto simples e o proxy sidecar crie uma conexão mTLS para o gateway.

Use uma regra de destino para cada host externo a fim de configurar o gateway de saída para "fazer upgrade" de solicitações HTTP simples para usar uma conexão TLS (HTTPS) ao encaminhar para o destino. O upgrade de uma conexão de texto simples para a TLS geralmente é chamado de origem da TLS.

Controlar o escopo da configuração de proxy com o recurso sidecar

Configure um recurso sidecar padrão para cada namespace a fim de controlar o comportamento dos proxies sidecar. Use o propriedade de saída do recurso de arquivo secundário para controlar e minimizar os hosts de destino configurados nos listeners de saída dos proxies. Uma configuração mínima típica pode incluir os seguintes destinos para cada namespace:

• Pods no mesmo namespace
• APIs e serviços do Google
• O servidor de metadados do GKE
• Hosts externos específicos que foram configurados usando entradas de serviço

A configuração dos listeners de saída em proxies sidecar não pode ser considerada como controles de segurança.

É uma prática recomendada usar os recursos do arquivo secundário para limitar o tamanho da configuração do proxy. Por padrão, cada proxy de arquivo sidecar em uma malha é configurado para permitir que ele envie tráfego a todos os outros proxies. O consumo de memória dos proxies sidecar e do plano de controle pode ser reduzido significativamente ao restringir a configuração de proxies apenas aos hosts com os quais eles precisam se comunicar.

Usar a política de autorização para permitir ou negar o tráfego no gateway de saída

AuthorizationPolicy é um recurso que permite configurar a política de controle de acesso refinada para o tráfego da malha. É possível criar políticas para permitir ou negar o tráfego com base nas propriedades da origem, do destino ou do próprio tráfego (por exemplo, o host ou cabeçalhos de uma solicitação HTTP).

Para permitir ou negar conexões com base na identidade ou no namespace da carga de trabalho de origem, a conexão com o gateway de saída precisa ser autenticada com o mTLS. As conexões de arquivos sidecar para o gateway de saída não usam automaticamente mTLS. Portanto, a regra de destino para conexões com o gateway precisa especificar explicitamente o modo TLS ISTIO_MUTUAL.

Para permitir ou negar solicitações no gateway usando políticas de autorização, as cargas de trabalho precisam enviar solicitações HTTP simples para destinos fora da malha. Os proxies sidecar podem, então, encaminhar a solicitação para o gateway usando o mTLS, e o gateway pode originar uma conexão TLS segura para o host externo.

Para aceitar os requisitos de saída de equipes e aplicativos diferentes, configure políticas de autorização de "privilégio mínimo" separadas por namespace ou carga de trabalho. Por exemplo, políticas diferentes podem ser aplicadas no gateway de saída com a especificação das regras com base no namespace da carga de trabalho de origem e nos atributos da solicitação. Isso é feito da seguinte maneira:

• Se o namespace de origem for team-x E o host de destino for example.com, então permite o tráfego.

  

• Se o namespace de origem for team-y E o host de destino for httpbin.org E o caminho for /status/418, permita o tráfego.

  

Todas as outras solicitações serão negadas.

Configurar o gateway de saída para originar conexões TLS (HTTPS) com o destino

Configure regras de destino para que o gateway de saída gere conexões TLS (HTTPS) com destinos externos.

Para que a origem TLS funcione no gateway de saída, as cargas de trabalho precisam enviar solicitações HTTP simples. Se a carga de trabalho iniciar a TLS, o gateway de saída une a TLS sobre a TLS original, e as solicitações para o serviço externo falharão.

Como as cargas de trabalho enviam solicitações HTTP simples, configure o proxy sidecar da carga de trabalho para estabelecer uma conexão mTLS ao enviá-las ao gateway. O gateway de saída encerra a conexão mTLS e gera uma conexão TLS (HTTPS) comum com o host de destino.

Essa abordagem tem várias vantagens:

• Use uma política de autorização para permitir ou negar o tráfego com base nos atributos da carga de trabalho de origem e nas solicitações.

• O tráfego entre os pods de carga de trabalho e o gateway de saída é criptografado e autenticado (mTLS) e o tráfego entre o gateway de saída e o destino é criptografado (TLS/HTTPS).

• Dentro da malha, os proxies sidecar podem observar e agir de acordo com as propriedades de solicitações HTTP (por exemplo, cabeçalhos), oferecendo opções adicionais de observabilidade e controle.

• O código do aplicativo pode ser simplificado. Os desenvolvedores não precisam lidar com certificados ou bibliotecas de cliente HTTPS, e a malha de serviço garante a comunicação segura com criptografias padrão e atualizadas.

• As conexões TLS que o gateway de saída origina para serviços externos podem ser reutilizadas para o tráfego de muitos pods. A reutilização de conexão é mais eficiente e reduz o risco de os limites de conexão serem atingidos.

DNS, nomes do host e caracteres curinga

Ao rotear, negar ou permitir tráfego com base no host de destino, você precisa ter total confiança na integridade dos sistemas DNS para resolver nomes DNS no endereço IP correto. Nos clusters do Kubernetes Engine, o serviço DNS do Kubernetes processa consultas DNS e, por sua vez, delega consultas externas ao servidor de metadados do GKE e ao DNS interno. Defina o atributo de resolução de entradas de serviço como DNS ao rotear para hosts externos, de modo que os proxies sidecar sejam responsáveis por fazer consultas DNS.

O Cloud Service Mesh pode rotear o tráfego com base em hosts curinga. O caso mais simples é um caractere curinga para hosts que compartilham um nome comum e estão hospedados em um conjunto comum de servidores. Por exemplo, se um único conjunto de servidores puder veicular os domínios correspondentes por *.example.com, um host curinga poderá ser usado.

Um gateway de saída padrão não pode encaminhar com base em hosts de caracteres curinga mais gerais e arbitrários (por exemplo, *.com) devido a certas limitações do proxy Envoy usado pelo Istio. O Envoy só pode rotear o tráfego para hosts predefinidos, endereços IP predefinidos ou para o endereço IP de destino original de uma solicitação. Durante o uso de um gateway de saída, o IP de destino original da solicitação é perdido porque é substituído pelo IP do gateway e os hosts de destino arbitrários não podem ser pré-configurados.

Aplicação administrativa de políticas

Usar o controle de acesso baseado em papéis (RBAC, na sigla em inglês) do Kubernetes

Somente os administradores autorizados precisam configurar os controles de saída. Configure o Kubernetes Role Based Access Control (RBAC) para evitar fraude não autorizada de controles de saída. Aplique papéis RBAC para que apenas administradores de rede possam gerenciar os namespaces istio-egress, istio-system, e kube-system e os seguintes recursos:

• Arquivo secundário
• ServiceEntry
• Gateway
• AuthorizationPolicy
• NetworkPolicy

Como restringir o uso de tolerâncias

Como descrito anteriormente, é possível usar taints e tolerâncias para evitar que os pods de carga de trabalho sejam implantados em nós de gateway. No entanto, por padrão, não há nada que evite que cargas de trabalho sejam implantadas com uma tolerância para os nós de gateway e, portanto, permitem que os controles de saída sejam ignorados. Se for possível aplicar o controle administrativo centralizado sobre os pipelines de implantação, você poderá usá-los para aplicar restrições ao uso de determinadas chaves de tolerância.

Outra abordagem é usar o controle de admissão do Kubernetes. O Anthos inclui um componente chamado Policy Controller, que atua como um controlador de admissão do Kubernetes. Ele valida que as implantações atendam às restrições de política que você especificou.

Verifique se o tráfego foi registrado

Muitas vezes, é necessário registrar todo o tráfego que passa pelos perímetros de rede. A geração de registros de tráfego é essencial caso você precise demonstrar conformidade com regulamentações comuns de proteção de dados. Os registros de tráfego são enviados diretamente Cloud Logging (em inglês) e pode ser acessado nos painéis do Cloud Service Mesh no console do Google Cloud. É possível filtrar registros com base em vários atributos, incluindo origem/destino, identidade, namespace, atributos do tráfego e latência.

Para facilitar a depuração com o kubectl, ative a geração de registros de tráfego para stdout ao instalar o Cloud Service Mesh usando a configuração accessLogFile.

Os registros de auditoria são enviados para o Cloud Logging toda vez que o Mesh CA cria um certificado para uma carga de trabalho.

Use um cluster separado para gateways de saída em malhas de vários clusters

O Cloud Service Mesh pode ser implantadas em mais de um cluster do GKE. As malhas de vários clusters apresentam novas possibilidades para controlar o tráfego de saída e algumas limitações.

Em vez de implantar o gateway de saída em um pool de nós dedicado, é possível implantar o gateway em um cluster separado que não executa cargas de trabalho regulares. O uso de um cluster separado fornece um isolamento similar entre cargas de trabalho e gateways, evitando a necessidade de taints e tolerâncias. O gateway de saída pode compartilhar o cluster separado com gateways de entrada ou outros serviços centrais.

É possível usar as políticas de rede do Kubernetes em implantações de vários clusters. No entanto, como operam na Camada 4 (transporte), elas não podem restringir conexões entre clusters com base no namespace de destino ou no pod.

A seguir

• Consulte o guia de aumento da proteção do GKE.
• Saiba como gerenciar a configuração e a política em toda a infraestrutura com o Anthos Configuration Management.
• Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.