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 (por exemplo, GDPR) e 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 no serviço de código aberto Istio da rede mesh. 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. Implante gateways de saída com um escalonador automático horizontal de pods para que o número de réplicas seja escalonado verticalmente.
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. Para permitir que as cargas de trabalho se conectem a hosts externos sem precisar de endereços IP públicos, configure o Cloud NAT para fornecer a 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 se baseia em namespaces do Kubernetes ao usá-los como uma 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.
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-systemeistio-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). Malha de serviço do Cloud fornece uma CA gerenciada e a expõe como uma API. Assim, os proxies sidecar precisam consiga se conectar a ele. 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 da malha de serviço
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.
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
recurso sidecar
padrão 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
Configure as 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 será 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 a propriedade de saída do recurso sidecar 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 políticas detalhadas de controle de acesso para o tráfego da rede mesh. É 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 para o Cloud Logging e podem ser acessados 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 kubectl, ative a geração de registros de tráfego para stdout quando
para instalar o Cloud Service Mesh com o
Configuração de 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 implantado 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.