Política de rede

Para definir uma política de rede para cargas de trabalho de máquinas virtuais (VM) ao nível do espaço de nomes do projeto, use o recurso ProjectNetworkPolicy, uma política de rede de vários clusters para o Google Distributed Cloud air-gapped (GDC). Permite-lhe definir políticas, o que permite a comunicação nos projetos, entre projetos e com endereços IP externos.

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

Peça autorização e acesso

Para realizar as tarefas indicadas nesta página, tem de ter a função de administrador da NetworkPolicy do projeto. Peça ao administrador de IAM do projeto para lhe conceder a função de administrador da política de rede (project-networkpolicy-admin) no espaço de nomes do projeto onde reside a VM.

Tráfego entre projetos

Por predefinição, as cargas de trabalho de VMs num espaço de nomes do projeto têm a capacidade de 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 intraprojeto de entrada

Quando cria um projeto, cria uma base ProjectNetworkPolicy predefinida no servidor da API Management para permitir a comunicação dentro do projeto. Esta política permite o tráfego de entrada de outras cargas de trabalho no mesmo projeto. Pode removê-lo, mas tenha cuidado ao fazê-lo, uma vez que isto resulta na recusa da comunicação da carga de trabalho intralocal e do contentor.

Política de rede de tráfego intraprojeto de saída

Por predefinição, não tem de fazer nada relativamente à saída. Isto acontece porque, na ausência de uma política de saída, todo o tráfego é permitido. No entanto, quando define uma única política, apenas o tráfego especificado pela política é permitido.

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

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 VMs de diferentes espaços de nomes de projetos , mas na mesma organização, podem comunicar entre si aplicando uma política de rede entre projetos.

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

Para que as cargas de trabalho do projeto permitam ligações de outras cargas de trabalho noutro projeto, tem de configurar uma política de entrada para permitir que as cargas de trabalho do outro projeto transfiram dados para fora.

A seguinte política permite que as cargas de trabalho no projeto PROJECT_1 permitam ligações de cargas de trabalho no projeto PROJECT_2, bem como o tráfego de retorno para os mesmos fluxos. Se quiser aceder à sua VM no PROJECT_1 a partir de uma origem no PROJECT_2, também pode usar esta 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 aceda a PROJECT_1, mas não permite ligações iniciadas a partir de PROJECT_1 para PROJECT_2. Para este último, precisa de uma política recíproca no projeto do PROJECT_2. Execute o seguinte comando 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

Permitiu ligações iniciadas de e para PROJECT_1 e PROJECT_2.

Use as seguintes definições para as 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 entre projetos de saída

Quando concede uma política de tráfego entre projetos de entrada para permitir cargas de trabalho num projeto, PROJECT_1, para permitir ligações de cargas de trabalho noutro projeto, PROJECT_2, isto também concede o tráfego de retorno para os mesmos fluxos. Por conseguinte, não precisa de uma política de rede de tráfego entre projetos de saída.

Tráfego entre organizações

Para ligar uma carga de trabalho de VM a um destino fora do seu projeto que resida numa organização diferente, é necessária uma aprovação explícita. Essa aprovação deve-se à prevenção de roubo de dados, que o GDC ativa por predefinição e impede que um projeto tenha saída para cargas de trabalho fora da organização onde o projeto reside. As instruções para adicionar uma política de saída específica e ativar a exfiltração de dados são as seguintes nesta secção.

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

Para permitir o tráfego de entrada em diferentes organizações, tem de ser aplicada uma ProjectNetworkPolicy que permita o tráfego de clientes externos à organização para o seu projeto, por exemplo, estabelecer ligação à VM através de SSH.

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

Se quiser aceder à sua VM no PROJECT_1 a partir de uma origem fora da organização onde a VM está localizada, tem de aplicar a seguinte política para o fazer. Tem de obter e usar o CIDR que contém o seu endereço IP de origem. O CIDR deve estar na notação network/len. Por exemplo, 192.0.2.0/21 é um valor válido.

  1. Configure e aplique o seu Ingress ProjectNetworkPolicy, seguindo o exemplo kubectl. Aplique a política em todas as cargas de trabalho do utilizador em PROJECT_1. Permite o tráfego de entrada para todos os anfitriões em CIDR, que residem 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 seu projeto, ProjectNetworkPolicy. Uma vez que a prevenção de exfiltração de dados está ativada por predefinição, a sua saída personalizada ProjectNetworkPolicy mostra um erro de validação no campo de estado e o plano de dados ignora-o. Este processo ocorre por design.

Conforme indicado em Segurança e conetividade, as cargas de trabalho podem transferir dados quando permite a exfiltração de dados para um determinado projeto. O tráfego que permite a transferência de dados é uma tradução de endereços de rede (NAT) de origem que usa um endereço IP conhecido atribuído ao projeto. Segurança e conetividade também fornece detalhes sobre a aplicação (ProjectNetworkPolicy) da política de rede do projeto.

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

Ative a política de saída personalizada:

  1. Configure e aplique a sua própria saída personalizada ProjectNetworkPolicy, seguindo o exemplo kubectl. Aplique a política em todas as cargas de trabalho do utilizador em PROJECT_1. Permite o tráfego de saída para todos os anfitriões em CIDR, que residem fora da organização. A sua primeira tentativa provoca um erro de estado 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 que vê um erro de validação no seu estado.

  4. Peça ao utilizador administrador para desativar a prevenção de exfiltração de dados. Isto ativa a sua configuração, ao mesmo tempo que impede todas as outras saídas.

  5. Verifique o ProjectNetworkPolicy que acabou de criar e confirme que o erro no campo de estado de validação desapareceu e que o estado Ready é True, o que indica que a 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 com 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 CIDR (Classless Inter-Domain Routing) do destino permitido.
    NAMEUm nome associado ao destino.

    Depois de aplicar esta política e, desde que não tenha definido outras políticas de saída, todo o outro tráfego de saída é recusado para o PROJECT_1.