Vista geral

Esta página apresenta uma vista geral das políticas de rede de projetos no Google Distributed Cloud (GDC) air-gapped.

As políticas de rede de projetos definem regras de entrada ou saída. Ao contrário das políticas de rede do Kubernetes, só pode especificar um tipo de política para uma política. Cada regra numa política pode ser configurada com uma ação de Permitir (a predefinição) ou Negar.

Para o tráfego num projeto, o GDC aplica uma política de rede de projetos predefinida, a política intraprojeto, a cada projeto por predefinição.

Por predefinição, os serviços e as cargas de trabalho num projeto estão isolados de serviços e cargas de trabalho externos. No entanto, os serviços e as cargas de trabalho de diferentes espaços de nomes de projetos e na mesma organização podem comunicar entre si através da aplicação de políticas de rede de tráfego entre projetos.

Da mesma forma, a ligação de serviços e cargas de trabalho a um destino fora do seu projeto numa organização diferente requer aprovação explícita. Tem de desativar a proteção contra exfiltração de dados para permitir o tráfego externo à organização.

As regras de firewall de entrada e saída são os principais componentes das políticas de rede de projetos e determinam os tipos de tráfego permitidos ou negados na sua rede. Para definir regras de firewall para o espaço de nomes do projeto no GDC, use a consola do GDC.

Segurança e conetividade

Por predefinição, os serviços e as cargas de trabalho num projeto estão isolados nesse projeto. Não podem comunicar com serviços e cargas de trabalho externos sem configurar uma política de rede.

Para definir uma política de rede para o espaço de nomes do projeto no GDC, use o recurso ProjectNetworkPolicy. Este recurso permite-lhe definir políticas que permitem a comunicação dentro de projetos, entre projetos, para endereços IP externos e a partir de endereços IP externos. Além disso, só pode transferir cargas de trabalho de um projeto se desativar a proteção contra exfiltração de dados para o projeto.

As políticas de rede de projetos do GDC são cumulativas. A aplicação resultante para uma carga de trabalho é uma correspondência qualquer 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 de cada política são combinadas de forma cumulativa, permitindo o tráfego se corresponder a, pelo menos, uma das regras.

As regras Deny explícitas têm precedência absoluta sobre as regras Allow. Se um fluxo de tráfego corresponder a uma regra Deny, é ignorado, mesmo que seja permitido por outra regra ou por políticas de plataforma predefinidas.

Além disso, depois de aplicar uma única política que seleciona uma carga de trabalho, todo o tráfego que não especificar é negado (modo de negação predefinido). Por conseguinte, quando aplica uma ou mais políticas que selecionam uma carga de trabalho como assunto, só é permitido o tráfego explicitamente permitido (e não explicitamente negado).

Quando usa um endereço IP conhecido que atribui ao projeto, este realiza uma tradução de endereço de rede de origem (NAT) no tráfego de saída da organização.

Políticas de rede de projetos globais

Pode criar políticas de rede de projetos globais. O âmbito das políticas de rede de projetos globais abrange um universo do GDC. Cada universo do GDC pode consistir em várias zonas do GDC organizadas em regiões interligadas e que partilham um plano de controlo. Por exemplo, um universo composto por duas regiões com três zonas cada pode ter o seguinte aspeto: us-virginia1-a, us-virginia1-b, us-virginia1-c e eu-ams1-a, eu-ams1-b, eu-ams1-c.

O âmbito das políticas de rede de projetos zonais está limitado às zonas especificadas no momento da criação. Cada zona é um domínio de recuperação após desastre independente. Uma zona gere a infraestrutura, os serviços, as APIs e as ferramentas que usam um plano de controlo local.

Para mais informações sobre os recursos globais num universo do GDC, consulte a vista geral de várias zonas.

Pode criar políticas de rede de projetos globais através da API Networking Kubernetes Resource Model (KRM). Use a versão da API networking.global.gdc.goog para criar recursos globais.

Pode criar políticas de rede de projetos zonais através da API KRM ou da consola do GDC. Use a versão da API networking.gdc.goog para criar recursos zonais.

Políticas de rede de permissão total

Pode criar políticas de rede de permissão total para estabelecer regras de acesso predefinidas e amplas para um projeto.

Pode configurar os seguintes tipos de políticas de rede de permissão total:

  • Política de rede de permissão total: permite o tráfego de e para qualquer origem, o que inclui outros projetos e IPs externos.
  • Política de rede de permissão total externa: permite o tráfego de e para endereços IP externos à organização.
  • Política de rede de permissão total de projetos: permite o tráfego de e para todos os projetos na organização.

Para mais informações, consulte o artigo Crie políticas de rede de tráfego de permissão total.

Políticas de rede de negação explícita

Pode configurar regras de negação explícita em políticas de rede de projetos para restringir a conetividade entre projetos ou blocos CIDR especificados.

Principais funcionalidades e restrições das regras de negação:

  • Precedência: as regras de negação têm precedência absoluta sobre as regras de permissão (incluindo as políticas de plataforma base).
  • Regras de segurança de saída: para evitar o bloqueio acidental do tráfego de infraestrutura crítico, as regras de negação de saída excluem automaticamente os espaços de nomes do sistema e não relacionados com o projeto.
  • Restrição de pares: para garantir uma configuração segura, as regras de negação de entrada têm de especificar explicitamente um par de origem. Não pode selecionar todas as origens deixando o par de origem em branco. Deixar o par de origem em branco não é permitido e a política é rejeitada.
  • Sem negação de saída com DEP: não pode configurar regras de negação de saída quando a proteção contra exfiltração de dados (DEP) está ativada para o projeto.

Para mais informações, consulte o artigo Crie políticas de rede de negação.

Políticas de rede ao nível da carga de trabalho

Pode criar políticas de rede ao nível da carga de trabalho para definir um controlo de acesso detalhado para VMs e pods individuais num projeto. Estas políticas funcionam como firewalls para as suas cargas de trabalho, controlando o fluxo de tráfego com base em etiquetas para melhorar a segurança e isolar as aplicações. Esta granularidade permite um controlo mais rigoroso sobre as cargas de trabalho que podem comunicar entre si dentro e entre projetos.

As políticas de rede ao nível da carga de trabalho também oferecem a capacidade de aplicar a PNP numa única zona.

Para mais informações, consulte os artigos Crie uma política intraprojeto ao nível da carga de trabalho e Crie uma política entre projetos ao nível da carga de trabalho.

Prepare as funções e o acesso predefinidos

Para configurar políticas de rede de projetos, tem de ter as funções de identidade e acesso necessárias:

  • Administrador de ProjectNetworkPolicy: gere as políticas de rede de projetos no espaço de nomes do projeto. Peça ao administrador de IAM da organização para lhe conceder a função de cluster de administrador de ProjectNetworkPolicy (project-networkpolicy-admin).
  • Administrador de PNP global: tem autorizações de escrita em todos os recursos de PNP de várias zonas no espaço de nomes do projeto global. Peça ao administrador de IAM da organização para lhe conceder a função de administrador de PNP global (global-project-networkpolicy-admin). Para mais informações, consulte o artigo Descrições de funções predefinidas.

Considerações sobre a seleção de nós e a escala

Quando configura políticas de rede de projetos para segmentar nós específicos ou usa intervalos CIDR amplos, as suas opções de configuração de políticas podem ter um impacto na escalabilidade e no desempenho. Considere o seguinte:

Impacto de intervalos CIDR amplos na escalabilidade

  • Comportamento de 0.0.0.0/0: a utilização de um CIDR amplo, como 0.0.0.0/0, numa regra ipBlocks corresponde a todos os nós no cluster, além de IPs externos.
  • Escala: é atribuída a cada nó no cluster uma identidade CIDR única. Cada ponto final da carga de trabalho (VM ou pod) tem uma tabela de políticas interna subjacente (um mapa BPF) que armazena as respetivas regras de rede. Em clusters grandes, as regras ipBlocks amplas (como 0.0.0.0/0) aumentam a utilização do mapa de políticas na ordem do número de nós, porque o sistema tem de criar entradas para cada identidade CIDR de nó única.
  • Prática recomendada: evite usar intervalos CIDR excessivamente amplos em ipBlocks se tiver uma contagem de nós muito elevada ou um grande número de políticas complexas, uma vez que pode atingir o limite do mapa de políticas por ponto final. Se um ponto final atingir este limite, a aplicação de novas políticas de rede falha, o que pode interromper a conetividade de rede ou impedir a aplicação de políticas para essa carga de trabalho.

O que se segue?