A camada de rede virtual no Google Distributed Cloud (GDC) air-gapped rege a conetividade, as firewalls, a deteção de serviços, o equilíbrio de carga e a observabilidade entre máquinas virtuais e pods em execução numa organização do GDC.
Modelo de rede da GDC
O GDC contém dois níveis de conceitos de multi-inquilino: organizações e projetos. Os projetos existem nas organizações e implementa todas as cargas de trabalho virtualizadas e contentorizadas num projeto específico de uma organização.
Redes de organizações
Cada organização na GDC tem a sua própria rede virtual isolada. A rede virtual na organização é um espaço de IP simples, o que significa que todas as cargas de trabalho na organização têm uma ligação de endereço IP direta entre si. Com as políticas de rede do projeto, pode controlar o acesso entre cargas de trabalho em diferentes projetos na organização.
O GDC isola cada organização ao nível da rede de todas as outras organizações. As cargas de trabalho numa organização não têm conetividade direta de endereço IP com cargas de trabalho noutra organização.
Uma organização tem dois intervalos de IP diferentes: um intervalo interno e um intervalo externo. O intervalo de IPs externos é acessível a partir do exterior da organização, e o intervalo de IPs internos só é acessível a partir do interior da organização. As cargas de trabalho são sempre atribuídas a um endereço IP do intervalo interno da organização, o que significa que não são acessíveis a partir do exterior da organização por predefinição. Tem de ativar explicitamente o tráfego de entrada e saída para cargas de trabalho através das restrições de entrada e saída descritas na secção Redes de projetos.
Rede de projetos
Implementa todas as máquinas virtuais (VMs) e cargas de trabalho em contentores num projeto. Os projetos oferecem um limite de segmentação de rede na organização.
As cargas de trabalho num projeto podem comunicar diretamente entre si. No entanto, a política de rede predefinida impede a comunicação entre cargas de trabalho em projetos diferentes. As políticas de rede do projeto (ProjectNetworkPolicy) permitem-lhe configurar que projetos na organização podem comunicar entre si. Se a política de rede do projeto o permitir, as cargas de trabalho na organização podem alcançar-se mutuamente na camada de rede L3 através dos respetivos endereços IP. Tem de ativar explicitamente as restrições de entrada e saída para e a partir da organização para cada carga de trabalho que exija tráfego de entrada ou saída.
Configure balanceadores de carga
Os balanceadores de carga distribuem o tráfego pelas cargas de trabalho de back-end da sua aplicação, garantindo a estabilidade e a disponibilidade. Crie balanceadores de carga externos e internos para cargas de trabalho de VMs e pods. O GDC oferece três métodos para configurar balanceadores de carga. Para mais informações, consulte o artigo Faça a gestão dos equilibradores de carga.
Restrições de entrada
O mecanismo usado para expor cargas de trabalho fora da organização difere consoante a carga de trabalho se baseie em VMs ou contentores.
Expõe cargas de trabalho baseadas em VMs fora da organização através da capacidade de acesso externo da VM. Ativa esta capacidade para cada MV. Cada VM recebe o seu próprio endereço IP do intervalo externo da organização.
Por outro lado, expõe cargas de trabalho em contentores fora da organização através da funcionalidade de balanceador de carga externo. Pode criar um balanceador de carga externo e o GDC atribui um endereço IP externo. Em seguida, o tráfego pode ser equilibrado em carga num conjunto de cargas de trabalho de pods de back-end.
Restrições de saída
Tem de ativar explicitamente o tráfego de saída para cada projeto e carga de trabalho para comunicar fora da organização. A ativação do tráfego de saída altera o IP das cargas de trabalho para um IP externo através da tradução de endereços de rede (NAT) quando se liga fora da organização. Para mais informações sobre como permitir o tráfego de saída, consulte o artigo Faça a gestão do 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 numa organização é a união das políticas de rede do projeto predefinidas e criadas pelo utilizador.
A aplicação de políticas baseia-se nos fluxos de tráfego da camada 3 e da camada 4. Um fluxo descreve uma ligação de 5 tuplos da seguinte forma:
- 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 a aplicação de tráfego de saída no tráfego no nó que aloja a carga de trabalho de origem e a aplicação de tráfego de entrada quando o tráfego chega ao nó que aloja a carga de trabalho de destino. Por conseguinte, para estabelecer uma ligação, tem de permitir que a política saia da origem para o destino e chegue ao destino a partir da origem.
O tráfego de resposta, como o segmento SYN-ACK (synchronize-acknowledge) que responde a um segmento SYN, não está sujeito à aplicação. Por conseguinte, o tráfego de resposta é sempre permitido se o tráfego de iniciação for permitido. Por este motivo, só observa tempos limite de ligação devido à aplicação de políticas do cliente que inicia a ligação. O tráfego recusado é rejeitado 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 receção nunca observa a ligação.
A aplicação baseia-se em regras de políticas baseadas em permissões que são cumulativas. A aplicação resultante para uma carga de trabalho é "qualquer 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 existem várias políticas, as regras aplicadas a cada carga de trabalho são combinadas de forma aditiva, permitindo o tráfego se corresponder a, pelo menos, uma das regras. Não tem regras de recusa, apenas regras de permissão.
Quando uma política de rede nega um fluxo, não recebe um pacote de resposta e observa um limite de tempo da ligação. Por este motivo, quaisquer ligações ao nível do protocolo recusadas ou repostas, ou erros HTTP, 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.