Política de rede

Para definir uma política de rede para cargas de trabalho de máquina virtual (VM) no nível do namespace do projeto, use o recurso ProjectNetworkPolicy, uma política de rede multicluster para o appliance isolado do Google Distributed Cloud (GDC). Ela permite definir políticas, o que possibilita a comunicação dentro dos projetos, entre eles e com endereços IP externo.

Para o tráfego em um projeto, o GDC aplica uma política de rede predefinida, a política intraprojeto, a cada projeto por padrão. Para ativar e controlar o tráfego entre projetos na mesma organização, defina políticas entre projetos. Quando há várias políticas, o GDC combina as regras de cada projeto de forma aditiva. O GDC também permite tráfego se pelo menos uma das regras corresponder.

Solicitar permissão e acesso

Para executar as tarefas listadas nesta página, é preciso ter o papel de administrador do NetworkPolicy do projeto. Peça ao administrador do IAM do projeto para conceder a você o papel de Administrador da NetworkPolicy do projeto (project-networkpolicy-admin) no namespace do projeto em que a VM está localizada.

Tráfego no mesmo projeto

Por padrão, as cargas de trabalho de VM em um namespace de projeto podem se comunicar entre si sem expor serviços ao mundo externo, mesmo que as VMs façam parte de clusters diferentes no mesmo projeto.

Política de rede de tráfego de entrada entre projetos

Ao criar um projeto, você cria uma base ProjectNetworkPolicy padrão no servidor da API Management para permitir a comunicação entre projetos. Essa política permite o tráfego de entrada de outras cargas de trabalho no mesmo projeto. Você pode remover, mas tenha cuidado, porque isso nega a comunicação de carga de trabalho intraprojeto e de contêiner.

Política de rede de tráfego de saída entre projetos

Por padrão, não é necessário fazer nada em relação ao saída. Isso ocorre porque, na ausência de uma política de saída, todo o tráfego é permitido. No entanto, quando você define uma única política, apenas o tráfego especificado por ela é permitido.

Quando você desativa a Prevenção contra exfiltração de dados e aplica uma ProjectNetworkPolicy de saída ao projeto, como impedir o acesso a um recurso externo, use uma política obrigatória para permitir a saída intraprojeto:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-intra-project-egress-traffic
spec:
  policyType: Egress

  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_1
EOF

Tráfego entre projetos (na organização)

As cargas de trabalho de VM de diferentes namespaces de projetos , mas dentro da mesma organização, podem se comunicar entre si aplicando uma política de rede entre projetos.

Importante: essa política se aplica apenas a projetos na mesma organização que são de namespaces de projetos diferentes. Para ler sobre o tráfego entre organizações, que exige instruções específicas porque a prevenção contra exfiltração de dados protege contra toda saída desse tipo por padrão, consulte a seção Tráfego entre organizações.

Política de rede de tráfego entre projetos de entrada

Para que as cargas de trabalho do projeto permitam conexões de outras cargas de trabalho em outro projeto, configure uma política de entrada para permitir a entrada das cargas de trabalho do outro projeto.

A política a seguir permite que as cargas de trabalho no projeto PROJECT_1 aceitem conexões de cargas de trabalho no projeto PROJECT_2 e o tráfego de retorno para os mesmos fluxos. Execute o seguinte comando para aplicar a política:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_1
  name: allow-ingress-traffic-from-PROJECT_2
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_2
EOF

O comando anterior permite que PROJECT_2 acesse PROJECT_1, mas não permite conexões iniciadas de PROJECT_1 para PROJECT_2. Para o último caso, é necessário ter uma política recíproca no projeto PROJECT_2. Execute o comando a seguir para aplicar a política recíproca:

kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT_2
  name: allow-ingress-traffic-from-PROJECT_1
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
  - from:
    - projects:
        matchNames:
        - PROJECT_1
EOF

Agora você permitiu conexões iniciadas de e para PROJECT_1 e PROJECT_2.

Use as seguintes definições para suas variáveis.

Variável	Definição
MANAGEMENT_API_SERVER	O caminho do servidor da API Management kubeconfig.
PROJECT_1	O nome de um projeto do GDC correspondente a PROJECT_1 no exemplo.
PROJECT_2	O nome de um projeto do GDC correspondente a PROJECT_2 no exemplo.

Política de rede de tráfego de saída entre projetos

Quando você concede uma política de tráfego entre projetos de entrada para ativar cargas de trabalho em um projeto, PROJECT_1, para permitir conexões de cargas de trabalho em outro projeto, PROJECT_2, isso também concede o tráfego de retorno para os mesmos fluxos. Portanto, não é necessário ter uma política de rede de tráfego entre projetos de saída.

Tráfego entre organizações

Para conectar uma carga de trabalho de VM a um destino fora do seu projeto que reside em uma organização diferente, é necessária aprovação explícita. Essa aprovação é devido à prevenção de exfiltração de dados, que o GDC ativa por padrão e impede que um projeto tenha saída para cargas de trabalho fora da organização em que ele reside. As instruções para adicionar uma política de saída específica e ativar a exfiltração de dados estão nesta seção.

Política de rede de tráfego de entrada entre organizações

Quando você configura uma política de rede de saída entre organizações, não é necessário conceder entrada. O tráfego de saída permitido da carga de trabalho fora da sua organização passa por um balanceador de carga (LB, na sigla em inglês), e esse tráfego de saída é uma tradução de endereço de rede de origem (NAT, na sigla em inglês) usando um endereço IP alocado para o projeto.

Política de rede de tráfego de saída entre organizações

Para ativar o tráfego de saída para serviços fora da organização, personalize a política de rede do projeto, ProjectNetworkPolicy. No entanto, como a prevenção contra exfiltração de dados está ativada por padrão, seu ProjectNetworkPolicy de saída personalizado mostra um erro de validação no campo de status, e o plano de dados o ignora. Isso acontece por design.

As cargas de trabalho podem fazer egress quando você permite a exfiltração de dados para um determinado projeto. O tráfego de saída permitido é uma conversão de endereços de rede (NAT) de origem usando um endereço IP conhecido alocado para o projeto.

Estas instruções mostram como ativar sua política de saída personalizada:

1. Configure e aplique seu próprio Egress personalizado ProjectNetworkPolicy, seguindo o exemplo da CLI kubectl. Aplique a política a todas as cargas de trabalho do usuário em PROJECT_1. Ele permite o tráfego de saída para todos os hosts em CIDR, que residem fora da organização. A primeira tentativa causa um erro de status necessário, o que é intencional.

2. Aplique a configuração ProjectNetworkPolicy:

   kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
   apiVersion: networking.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT_1
     name: allow-egress-traffic-to-NAME
   spec:
     policyType: Egress
     subject:
       subjectType: UserWorkload
    egress:
     - to:
       - ipBlock:
           cidr: CIDR
   EOF
   

3. Quando terminar, confirme se um erro de validação aparece no seu status.

   Importante: apenas o tráfego de saída para destinos fora da organização do seu projeto que você permite explicitamente na configuração de saída do ProjectNetworkPolicy recebe saída. Todo o outro tráfego de saída é negado. Portanto, aplique um controle de saída ProjectNetworkPolicy personalizado somente quando os requisitos exigirem essa política.

4. Peça ao usuário administrador para desativar a prevenção contra exfiltração de dados. Isso ativa sua configuração e impede toda a saída.

   Importante: desativar a prevenção de exfiltração de dados sem definir um ou mais ProjectNetworkPolicys válidos permite que todo o tráfego de saída vá para destinos fora da organização do seu projeto. Nunca desative essa opção sem concluir primeiro a etapa 1 para configurar seu Egress ProjectNetworkPolicy personalizado.

5. Verifique o ProjectNetworkPolicy que você acabou de criar e confira se o erro no campo de status de validação desapareceu e se o status Ready é True, indicando que sua política está em vigor:

   kubectl --kubeconfig MANAGEMENT_API_SERVER get projectnetworkpolicy
   allow-egress-traffic-to-NAME -n PROJECT_1 -o yaml
   

   Substitua as variáveis usando as seguintes definições.

   Variável	Definição
   MANAGEMENT_API_SERVER	O arquivo kubeconfig do servidor da API Management.
   PROJECT_1	O nome do projeto do GDC.
   CIDR	O bloco de roteamento entre domínios sem classe (CIDR) do destino permitido.
   NAME	Um nome associado ao destino.

   Depois de aplicar essa política, e desde que você não tenha definido outras políticas de saída, todo o tráfego de saída será negado para PROJECT_1.