A camada de rede virtual no Google Distributed Cloud (GDC) isolado por air-gap governa a conectividade, os firewalls, a descoberta de serviços, o balanceamento de carga e a capacidade de observação 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 de multitenancy: 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 uma rede virtual isolada. A rede virtual dentro da organização é um espaço IP plano, o que significa que todas as cargas de trabalho na organização têm conectividade direta de endereço IP entre si. Com as políticas de rede do projeto, é possível controlar o acesso entre cargas de trabalho em diferentes projetos da organização.
O GDC isola cada organização no nível da rede de todas as outras. As cargas de trabalho em uma organização não têm conectividade direta de endereço IP com as 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 dela. 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. É preciso 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 do projeto.
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 na 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. Com as políticas de rede do projeto (ProjectNetworkPolicy), é possível 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 comunicar na camada de rede L3 usando os respectivos endereços IP. É necessário ativar explicitamente as restrições de entrada e saída para e da organização em 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 pods e VMs. 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 de elas serem baseadas em VMs ou contêineres.
Você expõe cargas de trabalho baseadas em VM fora da organização usando a capacidade de acesso externo da VM. Você ativa esse recurso para cada VM. Cada VM recebe um 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. Você pode 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 pods de back-end.
Restrições de saída
Você precisa ativar explicitamente o tráfego de saída para cada projeto e carga de trabalho se quiser se comunicar fora da organização. Ao ativar o tráfego de saída, o IP das cargas de trabalho muda para um IP externo usando a conversão de endereços de rede (NAT) ao se conectar fora da organização. Para mais informações sobre como permitir o tráfego de saída, consulte Gerenciar o tráfego de saída de uma organização.
Modelo de aplicação da política de rede
A postura de segurança para cargas de trabalho em uma organização é a união das políticas de rede do projeto padrão e criadas pelo usuário.
A aplicação de políticas é baseada em fluxos de tráfego das camadas 3 e 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
TCPouUDP
As políticas de rede aplicam o tráfego de saída no nó que hospeda a carga de trabalho de origem e o 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, você precisa 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 inicial for permitido. Por isso, você só vai observar 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 receptora nunca observa a conexão.
A imposição é baseada em regras de política de permissão que são cumulativas. A aplicação resultante para uma carga de trabalho é uma "correspondência de qualquer tipo" para o fluxo de tráfego em relação à união de todas as políticas aplicadas a essa carga de trabalho. Quando há várias políticas, as regras aplicadas a cada carga de trabalho são combinadas de forma aditiva, permitindo o tráfego se ele corresponder a pelo menos uma das regras. Você não tem regras de negação, apenas 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 isso, conexões recusadas ou redefinidas no nível do protocolo ou erros HTTP não são resultado direto da imposição de rede.
Para mais informações sobre políticas de rede do Kubernetes, consulte https://kubernetes.io/docs/concepts/services-networking/network-policies/#the-two-sorts-of-pod-isolation.