A camada de rede virtual no Google Distributed Cloud (GDC) air-gapped rege a conectividade, os firewalls, a descoberta de serviços, o balanceamento de carga e a observabilidade entre máquinas virtuais e pods em execução em uma organização do GDC.
Modelo de rede do GDC
O GDC contém dois níveis de conceitos multitenant: organizações e projetos. Os projetos existem dentro das organizações, e você implanta todas as cargas de trabalho virtualizadas e em contêineres em um projeto específico dentro de uma organização.
Rede da organização
Cada organização no GDC tem sua própria rede virtual isolada. A rede virtual dentro da organização é um espaço IP simples, o que significa que todas as cargas de trabalho na organização têm conectividade direta de endereço IP entre si. Usando políticas de rede de projeto, é possível controlar o acesso entre cargas de trabalho em diferentes projetos na organização.
O GDC isola cada organização no nível da rede de todas as outras organizações. As cargas de trabalho em uma organização não têm conectividade direta de endereço IP com cargas de trabalho em outra organização.
Uma organização tem dois intervalos de IP diferentes: um interno e um externo. O intervalo de IP externo pode ser acessado de fora da organização, e o intervalo de IP interno só pode ser acessado de dentro da organização. As cargas de trabalho sempre recebem um endereço IP do intervalo interno da organização, o que significa que elas não podem ser acessadas de fora da organização por padrão. É necessário ativar explicitamente o tráfego de entrada e saída para cargas de trabalho usando as restrições de entrada e saída descritas na seção Rede de projetos.
Rede de projetos
Você implanta todas as máquinas virtuais (VMs) e cargas de trabalho em contêineres em um projeto. Os projetos fornecem um limite de segmentação de rede dentro da organização.
As cargas de trabalho em um projeto podem se comunicar diretamente entre si. No entanto, a política de rede padrão impede a comunicação entre cargas de trabalho em projetos diferentes. As políticas de rede de projeto (ProjectNetworkPolicy) permitem configurar quais projetos na organização podem se comunicar entre si. Se a política de rede do projeto permitir, as cargas de trabalho na organização poderão se alcançar na camada de rede L3 usando os respectivos endereços IP. É necessário ativar explicitamente as restuação de entrada ingress e egress para e da organização para cada carga de trabalho que exige tráfego de entrada ou saída.
Configurar balanceadores de carga
Os balanceadores de carga distribuem o tráfego entre as cargas de trabalho de back-end do aplicativo, garantindo estabilidade e disponibilidade. Crie balanceadores de carga externos e internos para cargas de trabalho de pod e VM. O GDC oferece três métodos para configurar balanceadores de carga. Para mais informações, consulte Gerenciar balanceadores de carga.
Restrições de entrada
O mecanismo usado para expor cargas de trabalho fora da organização varia dependendo se a carga de trabalho é baseada em VMs ou contêineres.
Você expõe cargas de trabalho baseadas em VMs fora da organização usando o recurso de acesso externo da VM. Ative esse recurso para cada VM. Cada VM recebe seu próprio endereço IP do intervalo externo da organização.
Por outro lado, você expõe cargas de trabalho em contêineres fora da organização usando o recurso de balanceador de carga externo. É possível criar um balanceador de carga externo, e o GDC atribui um endereço IP externo. Em seguida, o tráfego pode ser balanceado por carga em um conjunto de cargas de trabalho de pod de back-end.
Restrições de saída
É necessário ativar explicitamente o tráfego de saída para que cada projeto e carga de trabalho se comuniquem fora da organização. A ativação do tráfego de saída muda o IP das cargas de trabalho para um IP externo usando a conversão de endereços de rede (NAT, na sigla em inglês) ao se conectar fora da organização. Para mais informações sobre como permitir o tráfego de saída, consulte Visão geral do NAT.
Modelo de aplicação de políticas de rede
A postura de segurança para cargas de trabalho em uma organização é a união das políticas de rede de projeto padrão e criadas pelo usuário do projeto.
A aplicação de políticas é baseada em fluxos de tráfego da camada 3 e da camada 4. Um fluxo descreve uma conexão de 5 tuplas da seguinte maneira:
- Endereço IP de origem
- Endereço IP de destino
- Porta de origem
- Porta de destino
- Protocolo, como
TCP,UDPouIPIP
As políticas de rede executam a aplicação de tráfego de saída no tráfego no nó que hospeda a carga de trabalho de origem e a aplicação de tráfego de entrada quando o tráfego chega ao nó que hospeda a carga de trabalho de destino. Portanto, para estabelecer uma conexão, é necessário permitir que a política saia da origem para o destino e chegue ao destino da origem.
O tráfego de resposta, como o segmento SYN-ACK (sincronizar-reconhecer) que responde a um segmento SYN, não está sujeito à aplicação. Portanto, o tráfego de resposta sempre é permitido se o tráfego de inicialização for permitido. Por esse motivo, você só observa tempos limite de conexão devido à aplicação de políticas do cliente que inicia a conexão. O tráfego negado é descartado durante a transferência de dados de saída do nó de origem ou a transferência de dados de entrada no nó de destino. A carga de trabalho de recebimento nunca observa a conexão.
A aplicação é baseada em regras de política baseadas em permissões que são cumulativas. A aplicação resultante para uma carga de trabalho é uma "correspondência" para o fluxo de tráfego em relação à união de todas as políticas aplicadas a essa carga de trabalho. Quando várias políticas estão presentes, as regras aplicadas a cada carga de trabalho são combinadas de forma cumulativa, permitindo o tráfego se ele corresponder a pelo menos uma das regras. Não há regras de negação, apenas regras de permissão.
Quando uma política de rede nega um fluxo, você não recebe um pacote de resposta e observa um tempo limite de conexão. Por esse motivo, todas as conexões ou erros HTTP recusados ou redefinidos no nível do protocolo não são um resultado direto da aplicação de rede.
Para mais informações sobre as políticas de rede do Kubernetes, consulte https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-two-sorts-of-pod-isolation (em inglês).