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

Este documento descreve como usar gateways de saída do Cloud Service Mesh e outros Google Cloud controlos para proteger o tráfego de saída de cargas de trabalho implementadas num cluster do Google Kubernetes Engine (GKE). Estes controlos podem limitar as ligações a serviços externos com base na identidade da aplicação de origem, no espaço de nomes de uma equipa, no domínio de destino e noutras propriedades dos pedidos de saída.

O público-alvo deste documento inclui engenheiros de rede, plataforma e segurança que administram clusters do GKE usados por uma ou mais equipas de entrega de software. Os controlos descritos aqui podem ser especialmente úteis para organizações que têm de demonstrar a conformidade com regulamentos (por exemplo, o RGPD e a PCI).

Introdução

A abordagem tradicional à segurança de rede tem sido definir perímetros de segurança em torno de um grupo de aplicações. As firewalls são usadas nestes perímetros para permitir ou negar tráfego com base nos endereços IP de origem e destino, ao mesmo tempo que confiam em aplicações e tráfego contidos no perímetro. No entanto, esta confiança envolve risco. Um insider malicioso ou qualquer pessoa que comprometa o perímetro pode mover-se livremente dentro da rede, aceder e exfiltrar dados, atacar sistemas de terceiros e interferir com os sistemas de administração.

Quando as cargas de trabalho executadas num cluster do Kubernetes estabelecem ligações de saída a anfitriões na Internet, a aplicação de controlos de segurança tradicionais baseados em IP pode ser complicada porque:

  • Os endereços IP dos pods não representam adequadamente a identidade da carga de trabalho que está a estabelecer a ligação. Num ambiente Kubernetes, os endereços IP dos pods são atribuídos de forma efémera e são reciclados com frequência à medida que os pods entram e saem.

  • Muitas vezes, é impossível identificar um conjunto pequeno e fixo de endereços IP para hosts de destino específicos. Os endereços IP mudam frequentemente, variam consoante a região e podem ser retirados de grandes intervalos ou representar caches, proxies ou CDNs.

  • Várias equipas que partilham o mesmo cluster multi-inquilino, com um intervalo partilhado de IPs de origem, podem ter requisitos de conetividade externa diferentes.

O Cloud Service Mesh é uma malha de serviço totalmente gerida no Google Cloud baseada na malha de serviço Istio de código aberto. Uma malha de serviços oferece uma forma uniforme de ligar, gerir e proteger a comunicação de aplicações. As malhas de serviços adotam uma abordagem centrada na aplicação e usam identidades de aplicações fidedignas em vez de uma abordagem focada no IP de rede.

Pode implementar uma malha de serviços de forma transparente sem necessidade de modificar o código da aplicação existente. A utilização de uma malha de serviços ajuda a separar o trabalho das equipas de desenvolvimento responsáveis pela entrega e lançamento de funcionalidades da aplicação das responsabilidades dos administradores de rede, fornecendo um controlo declarativo do comportamento da rede.

O Cloud Service Mesh oferece a opção de implementar proxies de encaminhamento autónomos,conhecidos como gateways de saída, no limite da malha. Este guia explica como as funcionalidades do proxy de gateway de saída podem ser combinadas com as funcionalidades do Google Cloud para controlar, autorizar e observar o tráfego de saída de cargas de trabalho implementadas num cluster do GKE.

componentes conceptuais

Arquitetura de defesa em profundidade

O diagrama abaixo mostra uma arquitetura que adota uma abordagem de defesa em profundidade para o controlo detalhado do tráfego de saída de um cluster usado por várias equipas. Os controlos baseiam-se nos controlos de rede da camada 4 (transporte) e da camada 7 (aplicação).

arquitetura geral

A arquitetura usa os seguintes recursos e controlos:

  • Um cluster privado do GKE: os nós num cluster privado do GKE só têm endereços IP internos e não estão ligados à Internet por predefinição.

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

  • Regras de firewall da nuvem virtual privada (VPC): Configura regras de firewall da VPC para aplicar controlos da camada 4 (transporte) a ligações de e para os nós no cluster do GKE. Pode aplicar regras de firewall da VPC a VMs com base em contas de serviço ou etiquetas de rede.

  • Pools de nós do GKE com contas de serviço diferentes: isto permite-lhe configurar diferentes regras de firewall a aplicar consoante o pool de nós ao qual um nó pertence.

  • Namespaces do Kubernetes: cria namespaces para cada equipa de modo a fornecer isolamento e controlo administrativo delegado. Os administradores de rede usam um espaço de nomes dedicado para implementar o gateway de saída e configurar o encaminhamento para anfitriões externos.

  • Políticas de rede do Kubernetes: As políticas de rede permitem-lhe aplicar controlos da camada 4 aos pods. Cada política de rede tem um âmbito de um espaço de nomes e pode ter um âmbito mais preciso para determinados pods num espaço de nomes.

  • Um gateway de saída: o tráfego que sai dos pods na malha é direcionado através de proxies de gateway de saída dedicados executados em nós dedicados. Implementa gateways de saída com um redimensionador automático de pods horizontal para que o número de réplicas seja aumentado ou diminuído com o tráfego.

  • Políticas de autorização: Use políticas de autorização de malha para aplicar controlos da camada 7 (aplicação) ao tráfego entre pods na malha e ao tráfego que sai da malha.

  • Recursos Sidecar: usa recursos Sidecar para controlar o âmbito da configuração dos proxies Sidecar em execução em cada pod de carga de trabalho. Pode usar o recurso Sidecar para configurar os espaços de nomes, os pods e os serviços externos visíveis para uma carga de trabalho.

  • Acesso privado Google: esta opção permite que os nós e os pods no cluster privado acedam às APIs Google e extraiam imagens Docker do Container Registry.

  • Workload Identity do GKE: Com o Workload Identity, pode usar o Identity and Access Management (IAM) para conceder autorizações de API a cargas de trabalho específicas de acordo com o princípio do menor privilégio, sem ter de processar segredos.

Configurar controlos de saída

Se usar o gateway de saída para proteger o tráfego de saída da sua malha, recomendamos que configure os controlos de defesa em profundidade descritos nesta secção.

Use o GKE privado com o Cloud NAT

Quando a segurança é importante, o primeiro requisito de muitas organizações é evitar atribuir endereços IP públicos às respetivas cargas de trabalho. Um cluster do GKE privado satisfaz este requisito. Pode configurar o modo VPC Native no cluster privado para que os pods e os serviços sejam atribuídos a endereços IP de intervalos secundários na VPC. Os endereços IP dos pods nativos de VPC são encaminháveis nativamente na rede VPC.

Algumas cargas de trabalho podem exigir acesso a serviços fora da rede VPC e à Internet. Para permitir que as cargas de trabalho se liguem a anfitriões externos sem precisarem de ter endereços IP públicos, configure o Cloud NAT para fornecer a tradução de endereços de rede (NAT).

Certifique-se de que o Cloud NAT está configurado para que a gateway de saída possa estabelecer um número suficiente de ligações simultâneas a destinos externos. Pode evitar o esgotamento de portas e problemas com os atrasos na reutilização de ligações definindo o número mínimo de portas por VM de forma adequada. Consulte a vista geral do endereço e da porta do Cloud NAT para ver mais detalhes. Aumentar o número de réplicas do gateway de saída pode ajudar a reduzir as probabilidades de conflitos de mapeamento independentes do ponto final.

Configure o acesso privado do Google para APIs e serviços Google

É provável que as suas cargas de trabalho precisem de ter acesso às APIs e aos serviços Google. Use o acesso privado à Google com zonas DNS personalizadas para permitir a conetividade de sub-redes VPC privadas às APIs Google através de um conjunto de quatro endereços IP. Quando usa estes endereços IP, não é necessário que os agrupamentos tenham endereços IP externos, e o tráfego nunca sai da rede Google. Pode usar private.googleapis.com (199.36.153.8/30) ou restricted.googleapis.com (199.36.153.4/30), consoante esteja a usar os VPC Service Controls.

Use o Workload Identity e a IAM para proteger ainda mais as APIs e os serviços Google

A utilização do Workload Identity é a forma recomendada de permitir que as cargas de trabalho do GKE se autentiquem com as APIs Google e que os administradores apliquem controlos de autorização de "privilégio mínimo" através do IAM.

Quando usa o acesso privado à Google, o Workload Identity e a IAM, pode permitir com segurança que os pods de carga de trabalho ignorem o gateway de saída e se liguem diretamente às APIs e aos serviços Google.

Use namespaces do Kubernetes para controlo administrativo

Os espaços de nomes são um recurso organizacional útil em ambientes com muitos utilizadores, equipas ou inquilinos. Podem ser considerados um cluster virtual e permitem que a responsabilidade administrativa pelos grupos de recursos do Kubernetes seja delegada a diferentes administradores.

Os espaços de nomes são uma funcionalidade importante para o isolamento do controlo administrativo. No entanto, por predefinição, não oferecem isolamento de nós, isolamento do plano de dados nem isolamento da rede.

O Cloud Service Mesh baseia-se nos namespaces do Kubernetes, usando-os como uma unidade de posse num service mesh. As políticas de autorização da malha e os recursos auxiliares podem restringir a visibilidade e o acesso com base no espaço de nomes, na identidade e nos atributos da camada 7 (aplicação) do tráfego de rede.

Da mesma forma, pode usar políticas de rede do Kubernetes para permitir ou negar ligaçõ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 num conjunto de nós de gateway dedicado oferece várias vantagens. Os nós virados para o exterior podem usar uma configuração reforçada e pode configurar regras de firewall da VPC para impedir que as cargas de trabalho alcancem diretamente os anfitriões externos. Os conjuntos de nós podem ser dimensionados automaticamente de forma independente através do dimensionamento automático de clusters.

Para permitir o controlo administrativo separado do gateway de saída, implemente-o num espaço de nomes istio-egress dedicado. No entanto, os espaços de nomes são um recurso ao nível do cluster e não é possível usá-los para controlar em que nós a implementação é executada. Para o controlo da implementação, use um seletor de nós para a implementação do gateway de saída, de modo que seja executado em nós etiquetados como membros do conjunto de nós do gateway.

Certifique-se de que apenas os pods de gateway podem ser executados em nós de gateway. Os outros pods devem ser repelidos dos nós de gateway. Caso contrário, os controlos de saída podem ser ignorados. Pode impedir que as cargas de trabalho sejam executadas em determinados nós através de manchas e tolerâncias. Deve contaminar os nós no conjunto de nós do gateway e adicionar uma tolerância correspondente à implementação do gateway de saída.

Aplique regras de firewall da VPC a nós específicos

Configura o encaminhamento da malha de serviços para direcionar o tráfego de saída dos workloads em execução no conjunto de nós predefinido através dos gateways de saída em execução no conjunto de nós do gateway. No entanto, a configuração de encaminhamento da malha não deve ser considerada um limite de segurança, uma vez que existem várias formas de uma carga de trabalho contornar os proxies da malha.

Para impedir que as cargas de trabalho das aplicações se liguem diretamente a anfitriões externos, aplique regras de firewall de saída restritivas aos nós no conjunto de nós predefinido. Aplique regras de firewall separadas aos nós de gateway para que os pods de gateway de saída executados nos mesmos possam estabelecer ligação a anfitriões externos.

Quando cria uma regra de firewall de VPC, especifica as portas e os protocolos que a regra de firewall permite ou nega, bem como a direção do tráfego ao qual se aplica. As regras de saída aplicam-se ao tráfego de saída e as regras de entrada aplicam-se ao tráfego de entrada. A predefinição para a saída é allow e a predefinição para a entrada é deny.

As regras de firewall são aplicadas por ordem com base num número de prioridade que pode especificar. As regras de firewall têm estado, o que significa que, se o tráfego específico de uma VM for permitido, o tráfego de retorno que usa a mesma ligação também é permitido.

O diagrama seguinte mostra como é possível aplicar regras de firewall separadas a nós em dois conjuntos de nós diferentes com base na conta de serviço atribuída a um nó. Neste caso, uma regra de firewall deny all predefinida nega o acesso de saída para toda a VPC. Para evitar substituir as regras de firewall predefinidas essenciais para o funcionamento do cluster, a sua regra deny all deve usar uma prioridade baixa, como 65535. É aplicada uma regra de firewall de saída aditiva e de maior prioridade aos nós de gateway para lhes permitir estabelecer ligação diretamente a anfitriões externos nas portas 80 e 443. O conjunto de nós predefinido não tem acesso a anfitriões externos.

node pool de firewall

Use políticas de rede do Kubernetes como uma firewall para pods e espaços de nomes

Use políticas de rede do Kubernetes para aplicar uma camada adicional de segurança como parte de uma estratégia de defesa em profundidade. As políticas de rede têm âmbito nos espaços de nomes e operam na camada 4 (transporte). Com as políticas de rede, pode restringir a entrada e a saída:

  • Entre espaços de nomes
  • Para agrupamentos num espaço de nomes
  • Para portas e blocos de IP específicos.

Depois de uma política de rede selecionar pods num espaço de nomes, todas as ligações que não sejam permitidas explicitamente são rejeitadas. Quando são aplicadas várias políticas de rede, o resultado é cumulativo e é uma união das políticas. A ordem pela qual as políticas são aplicadas não é importante.

Seguem-se alguns exemplos de políticas de rede:

  • Permita ligações de saída dos espaços de nomes da carga de trabalho para os espaços de nomes istio-system e istio-egress. Os pods têm de conseguir estabelecer ligação ao plano de controlo e à gateway de saída.
  • Permitir que as cargas de trabalho façam consultas DNS a partir dos espaços de nomes de cargas de trabalho para a porta 53 no espaço de nomes kube-system.
  • Opcionalmente, permita que as cargas de trabalho no mesmo espaço de nomes se liguem entre si.
  • Opcionalmente, permita ligações de saída entre os espaços de nomes usados por diferentes equipas de aplicações.
  • Permita ligações de saída dos espaços de nomes de cargas de trabalho aos VIPs para as APIs Google (expostas através do acesso privado Google). A Cloud Service Mesh oferece uma AC gerida e expõe-na como uma API, pelo que os proxies sidecar têm de conseguir estabelecer ligação à mesma. Também é provável que algumas cargas de trabalho precisem de acesso às APIs Google.
  • Permita ligações de saída dos espaços de nomes de cargas 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-se nas APIs Google.

Por predefinição, quando um proxy sidecar é injetado num pod de carga de trabalho, iptables são programadas regras para que o proxy capture todo o tráfego TCP recebido e enviado. No entanto, como mencionado anteriormente, existem formas de as cargas de trabalho ignorarem o proxy. As regras de firewall da VPC impedem o acesso direto de saída dos nós predefinidos que executam as cargas de trabalho. Pode usar políticas de rede do Kubernetes para garantir que não é possível nenhuma saída externa direta a partir dos espaços de nomes de cargas de trabalho e que é possível a saída para o espaço de nomes istio-egress.

Se também controlar a entrada com políticas de rede, tem de criar políticas de entrada que correspondam às suas políticas de saída.

Configuração e segurança da malha de serviço

As cargas de trabalho executadas numa malha de serviços não são identificadas com base nos respetivos endereços IP. A Cloud Service Mesh atribui uma identidade forte e validável sob a forma de um certificado X.509 e uma chave para cada carga de trabalho. A comunicação fidedigna entre cargas de trabalho é estabelecida através de ligações TLS mútuo (mTLS) autenticadas e encriptadas.

A utilização da autenticação mTLS com uma identidade bem definida para cada aplicação permite-lhe usar políticas de autorização de malha para um controlo detalhado sobre a forma como as cargas de trabalho podem comunicar com serviços externos.

Embora o tráfego possa sair da malha diretamente dos proxies sidecar, se precisar de controlo adicional, recomendamos que encaminhe o tráfego através de gateways de saída, conforme descrito neste guia.

Faça a gestão da configuração dos controlos de saída num espaço de nomes dedicado

Permitir que os administradores de rede geram os controlos centralmente através de um espaço de nomes istio-egressdedicado para a configuração da malha relacionada com a saída. Conforme recomendado anteriormente, implemente o gateway de saída no espaço de nomes istio-egress. Pode criar e gerir entradas de serviços, gateways e políticas de autorização neste espaço de nomes.

Exija a configuração explícita de destinos externos

Certifique-se de que os proxies de malha só estão programados com rotas para anfitriões externos que estão explicitamente definidos no registo da malha de serviços. Defina o modo de política de tráfego de saída como REGISTRY_ONLY num recurso sidecar predefinido para cada espaço de nomes. A definição da política de tráfego de saída para a malha não deve, por si só, ser considerada um controlo de perímetro seguro.

Defina destinos externos com entradas de serviço

Configure as entradas de serviço para registar explicitamente os anfitriões externos no registo de serviços da malha. Por predefinição, as entradas de serviço são visíveis para todos os espaços de nomes. Use o atributo exportTo para controlar a que espaços de nomes uma entrada de serviço é visível. As entradas de serviço determinam as rotas de saída configuradas em proxies de malha, mas não devem, por si só, ser consideradas um controlo seguro para determinar a que anfitriões externos as cargas de trabalho se podem ligar.

Configure o comportamento do gateway de saída com o recurso Gateway

Configure o comportamento de equilíbrio de carga dos gateways de saída através do recurso Gateway. O balanceador de carga pode ser configurado para um conjunto específico de anfitriões, protocolos e portas, e associado a uma implementação de gateway de saída. Por exemplo, um gateway pode ser configurado para saída para as portas 80 e 443 para qualquer anfitrião externo.

No Cloud Service Mesh, o mTLS automático está ativado por predefinição. Com o mTLS automático, um proxy sidecar do lado do cliente deteta automaticamente se o servidor tem um sidecar. O contentor auxiliar do cliente envia mTLS para cargas de trabalho com contentores auxiliares e envia tráfego de texto simples para cargas de trabalho sem contentores auxiliares. Mesmo com o mTLS automático, o tráfego enviado para o gateway de saída a partir de proxies sidecar não usa automaticamente o mTLS. Para indicar como as ligações ao gateway de saída devem ser protegidas, tem de definir o modo TLS no recurso Gateway. Sempre que possível, use mTLS para ligações de proxies sidecar ao gateway de saída.

É possível permitir que as cargas de trabalho iniciem elas próprias ligações TLS (HTTPS). Se as cargas de trabalho originarem ligações TLS, normalmente na porta 443, tem de configurar o gateway para usar o modo passthrough para ligações nessa porta. No entanto, a utilização do modo passthrough significa que a gateway não pode aplicar políticas de autorização com base na identidade da carga de trabalho ou nas propriedades do pedido encriptado. Além disso, atualmente não é possível usar o mTLS e o passthrough em conjunto.

tls pass through

Configure os serviços virtuais e as regras de destino para encaminhar o tráfego através do gateway

Use os serviços virtuais e as regras de destino para configurar o encaminhamento do tráfego de proxies sidecar através do gateway de saída para destinos externos. Os serviços virtuais definem regras para a correspondência de determinado tráfego. Em seguida, o tráfego correspondente é enviado para um destino. As regras de destino podem definir subconjuntos (por exemplo, o gateway de saída ou um anfitrião externo) e como o tráfego deve ser processado quando é encaminhado para o destino.

Use uma única regra de destino para vários anfitriões de destino para especificar explicitamente como o tráfego de proxies sidecar para o gateway deve ser protegido. Conforme explicado anteriormente, o método preferencial é que as cargas de trabalho enviem pedidos de texto simples e que o proxy sidecar origine uma ligação mTLS ao gateway.

Use uma regra de destino para cada anfitrião externo para configurar o gateway de saída de modo a "atualizar" os pedidos HTTP simples para usar uma ligação TLS (HTTPS) quando encaminhar para o destino. A atualização de uma ligação de texto simples para TLS é frequentemente denominada originação TLS.

Controle o âmbito da configuração do proxy com o recurso Sidecar

Configure um recurso Sidecar predefinido para cada espaço de nomes para controlar o comportamento dos proxies sidecar. Use a propriedade de saída do recurso Sidecar para controlar e minimizar os anfitriões de destino configurados nos ouvintes de saída dos proxies. Uma configuração mínima típica pode incluir os seguintes destinos para cada espaço de nomes:

  • Pods no mesmo espaço de nomes
  • APIs e serviços Google
  • O servidor de metadados do GKE
  • Anfitriões externos específicos que foram configurados através de entradas de serviço

A configuração dos ouvintes de saída em proxies sidecar não deve, por si só, ser considerada como controlos de segurança.

É uma prática recomendada usar recursos do Sidecar para limitar o tamanho da configuração do proxy. Por predefinição, cada proxy paralelo numa malha está configurado para permitir o envio de tráfego para todos os outros proxies. O consumo de memória dos proxies sidecar e do plano de controlo pode ser muito reduzido restringindo a configuração dos proxies apenas aos anfitriões com os quais precisam de comunicar.

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

AuthorizationPolicy é um recurso que lhe permite configurar uma política de controlo de acesso detalhado para o tráfego de malha. Pode criar políticas para permitir ou recusar tráfego com base nas propriedades da origem, do destino ou do próprio tráfego (por exemplo, o anfitrião ou os cabeçalhos de um pedido HTTP).

Para permitir ou negar ligações com base na identidade ou no espaço de nomes da carga de trabalho de origem, a ligação ao gateway de saída tem de ser autenticada com mTLS. As ligações dos sidecars ao gateway de saída não usam automaticamente o mTLS, pelo que a regra de destino para ligações ao gateway tem de especificar explicitamente o modo TLS ISTIO_MUTUAL.

Para permitir ou negar pedidos no gateway através de políticas de autorização, as cargas de trabalho devem enviar pedidos HTTP simples para destinos fora da malha. Em seguida, os proxies sidecar podem encaminhar o pedido para o gateway através de mTLS e o gateway pode originar uma ligação TLS segura para o anfitrião externo.

Para suportar os requisitos de saída de diferentes equipas e aplicações, configure políticas de autorização de "privilégio mínimo" separadas por espaço de nomes ou carga de trabalho. Por exemplo, podem ser aplicadas políticas diferentes no gateway de saída especificando regras com base no espaço de nomes da carga de trabalho de origem e nos atributos do pedido da seguinte forma:

  • Se o espaço de nomes de origem for team-x E o anfitrião de destino for example.com, permita o tráfego.

    Exemplo de políticas de autorização

  • Se o espaço de nomes de origem for team-y E o anfitrião de destino for httpbin.org E o caminho for /status/418, então permita o tráfego.

    políticas de autorização através do httpbin

Todos os outros pedidos são recusados.

Configure o gateway de saída para originar ligações TLS (HTTPS) ao destino

Configure regras de destino para que o gateway de saída origine ligações TLS (HTTPS) a destinos externos.

Para que a origem do TLS no gateway de saída funcione, as cargas de trabalho têm de enviar pedidos HTTP simples. Se a carga de trabalho iniciar o TLS, o gateway de saída envolve o TLS em cima do TLS original e os pedidos ao serviço externo falham.

Uma vez que as cargas de trabalho estão a enviar pedidos HTTP simples, configure o proxy sidecar da carga de trabalho para estabelecer uma ligação mTLS quando os enviar para o gateway. Em seguida, o gateway de saída termina a ligação mTLS e origina uma ligação TLS (HTTPS) normal ao anfitrião de destino.

Originação de TLS no gateway de saída

Esta abordagem tem várias vantagens:

  • Pode usar uma política de autorização para permitir ou negar tráfego com base nos atributos da carga de trabalho de origem e dos pedidos.

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

  • Na malha, os proxies sidecar podem observar e agir com base nas propriedades dos pedidos HTTP (por exemplo, cabeçalhos), oferecendo opções adicionais de observabilidade e controlo.

  • O código da aplicação pode ser simplificado. Os programadores não precisam de lidar com certificados nem bibliotecas de clientes HTTPS, e a malha de serviços pode garantir uma comunicação segura com cifras padrão e atualizadas.

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

DNS, nomes de anfitrião e carateres universais

Quando encaminha, nega ou permite tráfego com base no anfitrião de destino, tem de confiar totalmente na integridade dos seus sistemas DNS para resolver nomes DNS para o endereço IP correto. Nos clusters do Kubernetes Engine, o serviço DNS do Kubernetes processa as consultas DNS e, por sua vez, delega as consultas externas para o servidor de metadados do GKE e o DNS interno. Defina o atributo de resolução das entradas de serviço para DNS quando encaminhar para anfitriões externos, para que os proxies auxiliares sejam responsáveis por fazer consultas DNS.

O Cloud Service Mesh pode encaminhar o tráfego com base em anfitriões com carateres universais. O caso mais simples é um caráter universal para anfitriões que partilham um nome comum e estão alojados num conjunto comum de servidores. Por exemplo, se um único conjunto de servidores puder servir os domínios que correspondem a *.example.com, pode usar um anfitrião com caráter universal.

Um gateway de saída padrão não pode encaminhar com base em anfitriões com carateres universais mais gerais e arbitrários (por exemplo, *.com) devido a determinadas limitações do proxy Envoy usado pelo Istio. O Envoy só pode encaminhar tráfego para anfitriões predefinidos, endereços IP predefinidos ou para o endereço IP de destino original de um pedido. Quando usa um gateway de saída, o IP de destino original do pedido é perdido porque é substituído pelo IP do gateway e não é possível pré-configurar os anfitriões de destino arbitrários.

Aplicação administrativa de políticas

Use o controlo de acesso baseado em funções (CABF) do Kubernetes

Apenas os administradores autorizados devem poder configurar os controlos de saída. Configure o controlo de acesso baseado em funções (CABF) do Kubernetes para evitar a circumvenção não autorizada dos controlos de saída. Aplique funções de CABF para que apenas os administradores de rede possam gerir os espaços de nomes istio-egress,istio-system, e kube-system, bem como os seguintes recursos:

  • Sidecar
  • ServiceEntry
  • Gateway
  • AuthorizationPolicy
  • NetworkPolicy

Restrição da utilização de tolerâncias

Conforme descrito anteriormente pode usar taints e tolerations para impedir a implementação de Pods de carga de trabalho em nós de gateway. No entanto, por predefinição, não existe nada que impeça a implementação de cargas de trabalho com uma tolerância para os nós de gateway e, por conseguinte, permita que os controlos de saída sejam ignorados. Se for possível aplicar um controlo administrativo centralizado sobre os pipelines de implementação, pode usá-los para aplicar restrições à utilização de determinadas chaves de tolerância.

Outra abordagem é usar o controlo de admissão do Kubernetes. O Anthos inclui um componente denominado Policy Controller que funciona como um controlador de admissão do Kubernetes e valida se as implementações cumprem as restrições de políticas que especificar.

Certifique-se de que o tráfego é registado

Muitas vezes, é necessário registar todo o tráfego que atravessa os perímetros da rede. O registo de tráfego é essencial se tiver de demonstrar a conformidade com os regulamentos de proteção de dados comuns. Os registos de tráfego são enviados diretamente para o Cloud Logging e podem ser acedidos a partir dos painéis de controlo do Cloud Service Mesh na Google Cloud consola. Pode filtrar os registos com base em vários atributos, incluindo origem/destino, identidade, espaço de nomes, atributos do tráfego e latência.

Para permitir uma depuração fácil com o kubectl, ative o registo de tráfego para o stdout quando instalar o Cloud Service Mesh através da definição accessLogFile.

Os registos de auditoria são enviados para o Cloud Logging sempre que a AC de malha cria um certificado para uma carga de trabalho.

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

O Cloud Service Mesh pode ser implementado em mais do que um cluster do GKE. As malhas de vários clusters introduzem novas possibilidades de controlar o tráfego de saída e também algumas limitações.

Em vez de implementar o gateway de saída num conjunto de nós dedicado, pode implementar o gateway num cluster separado que não execute cargas de trabalho normais. A utilização de um cluster separado oferece um isolamento semelhante entre cargas de trabalho e gateways, evitando a necessidade de taints e tolerâncias. O gateway de saída pode partilhar o cluster separado com gateways de entrada ou outros serviços centrais.

Pode usar políticas de rede do Kubernetes em implementações de vários clusters, mas, como operam na camada 4 (transporte), não podem restringir as ligações entre clusters com base no espaço de nomes ou no pod de destino.

O que se segue?