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 Google Distributed Cloud isolado (GDC). Ele permite definir políticas, o que permite a comunicação dentro de projetos, entre projetos 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 essa permissão, mas tome cuidado ao fazer isso, já que isso resulta na negação da comunicação entre projetos e cargas de trabalho de contêineres.

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.

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 que as cargas de trabalho do outro projeto transfiram dados para fora.

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. Se você quiser acessar sua VM no PROJECT_1 de uma origem dentro do PROJECT_2, também poderá usar essa política. 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ávelDefinição
MANAGEMENT_API_SERVERO caminho do servidor da API Management kubeconfig.
PROJECT_1O nome de um projeto do GDC correspondente a PROJECT_1 no exemplo.
PROJECT_2O 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

Para permitir o tráfego de entrada em diferentes organizações, é necessário aplicar uma ProjectNetworkPolicy que permita o tráfego de clientes externos da organização para seu projeto, por exemplo, conecte-se à VM usando SSH.

Uma política de saída correspondente não é necessária para o tráfego de resposta. O tráfego de retorno é permitido implicitamente.

Se você quiser acessar sua VM no PROJECT_1 de uma fonte fora da organização em que a VM reside, aplique a seguinte política para fazer isso. É preciso acessar e usar o CIDR que contém seu endereço IP de origem. O CIDR precisa estar na notação network/len. Por exemplo, 192.0.2.0/21 é um valor válido.

  1. Configure e aplique a Entrada ProjectNetworkPolicy, seguindo o exemplo kubectl. Aplique a política a todas as cargas de trabalho do usuário em PROJECT_1. Ele permite o tráfego de entrada para todos os hosts em CIDR, que estão fora da organização.

  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-external-traffic
spec:
  policyType: Ingress
  subject:
    subjectType: UserWorkload
  ingress:
   - from:
     - ipBlock:
         cidr: CIDR
EOF

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

Para ativar a transferência de dados para serviços fora da organização, personalize a política de rede do projeto, ProjectNetworkPolicy. 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.

Conforme declarado em Segurança e conectividade, as cargas de trabalho podem transferir dados quando você permite a exfiltração de dados de um determinado projeto. O tráfego permitido para transferência de dados para fora é uma conversão de endereços de rede (NAT) de origem usando um endereço IP conhecido alocado para o projeto. Segurança e conectividade também fornecem detalhes sobre a aplicação da política de rede do projeto (ProjectNetworkPolicy).

Uma política de entrada correspondente não é necessária para o tráfego de resposta. O tráfego de retorno é permitido implicitamente.

Ative sua política de saída personalizada:

  1. Configure e aplique seu próprio Egress personalizado ProjectNetworkPolicy, seguindo o exemplo 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.

  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.

  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ávelDefinição
    MANAGEMENT_API_SERVERO caminho kubeconfig do servidor da API Management.
    PROJECT_1O nome do projeto do GDC.
    CIDRO bloco de roteamento entre domínios sem classe (CIDR) do destino permitido.
    NAMEUm 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.