Crie políticas de rede entre projetos

Esta página fornece instruções para configurar políticas de rede de tráfego entre projetos no Google Distributed Cloud (GDC) air-gapped.

O tráfego entre projetos refere-se à comunicação entre serviços e cargas de trabalho de diferentes espaços de nomes de projetos, mas dentro da mesma organizaçã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 dentro da mesma organização podem comunicar entre si aplicando políticas de rede de tráfego entre projetos.

Por predefinição, estas políticas aplicam-se globalmente em todas as zonas. Para mais informações sobre os recursos globais num universo da GDC, consulte o artigo Vista geral de várias zonas.

Se for necessária a aplicação de políticas de tráfego entre projetos numa única zona, consulte o artigo Crie uma política entre projetos ao nível da carga de trabalho de uma única zona.

Antes de começar

Para configurar políticas de rede de tráfego entre projetos, tem de ter o seguinte:

• As funções de identidade e acesso necessárias. Para gerir políticas de um projeto específico, precisa da função project-networkpolicy-admin. Para ambientes multizona onde tem de gerir políticas que abrangem todas as zonas, precisa da função global-project-networkpolicy-admin. Para mais informações, consulte o artigo Prepare funções e acesso predefinidos.
• Um projeto existente. Para mais informações, consulte Crie um projeto.

Crie uma política entre projetos

Pode definir políticas de tráfego de entrada ou saída entre projetos para gerir a comunicação entre projetos.

Crie uma política entre projetos de entrada

Para que as cargas de trabalho ou os serviços do projeto permitam ligações de outras cargas de trabalho noutro projeto na sua organização, tem de configurar uma regra de firewall de entrada para permitir o tráfego de entrada de outras cargas de trabalho do projeto.

Esta política aplica-se a todas as zonas na sua organização.

Siga os passos seguintes para criar uma nova regra de firewall e permitir o tráfego de entrada de cargas de trabalho noutro projeto:

Consola

1. Na consola do GDC do projeto que está a configurar, aceda a Rede > Firewall no menu de navegação para abrir a página Firewall.
2. Clique em Criar na barra de ações para começar a criar uma nova regra de firewall.

3. Na página Detalhes da regra de firewall, preencha as seguintes informações:

   1. No campo Nome, introduza um nome válido para a regra de firewall.
   2. Na secção Direção do tráfego, selecione Entrada para permitir o tráfego de entrada de cargas de trabalho noutros projetos.
   3. Na secção Segmentar, selecione uma das seguintes opções:
      • Todas as cargas de trabalho do utilizador: permite ligações às cargas de trabalho do projeto que está a configurar.
      • Serviço: indica que esta regra de firewall destina-se a um serviço específico no projeto que está a configurar.
   4. Se o seu alvo for um serviço de projeto, selecione o nome do serviço na lista de serviços disponíveis no menu pendente Serviço.
   5. Na secção De, selecione uma das seguintes opções:
      • Todos os projetos: permite ligações de cargas de trabalho em todos os projetos da mesma organização.
      • Outro projeto e Todas as cargas de trabalho do utilizador: permitem ligações de cargas de trabalho noutro projeto da mesma organização.
   6. Se quiser transferir cargas de trabalho apenas de outro projeto, selecione um projeto ao qual tenha acesso na lista de projetos no menu pendente ID do projeto.
   7. Se o destino for todas as cargas de trabalho do utilizador, selecione uma das seguintes opções na secção Protocolos e portas:
      • Permitir tudo: permitir ligações através de qualquer protocolo ou porta.
      • Protocolos e portas especificados: permitem ligações que usam apenas os protocolos e as portas que especificar nos campos correspondentes para a regra da firewall de entrada.

4. Na página Detalhes da regra de firewall, clique em Criar.

Permitiu ligações de outras cargas de trabalho do projeto na mesma organização. Depois de criar a regra de firewall, esta fica visível numa tabela na página Firewall.

API

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. Aplique a política:

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

Substitua GLOBAL_API_SERVER pelo caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.

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 PROJECT_2. Aplique a política de reciprocidade:

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

As ligações são agora permitidas de e para PROJECT_1 e PROJECT_2.

Crie uma política entre projetos de saída

Quando concede uma política de tráfego entre projetos de entrada para permitir que as cargas de trabalho num projeto permitam ligações de cargas de trabalho noutro projeto, esta ação 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 no projeto original.

Por exemplo, se criar uma política que permita o tráfego de PROJECT_1 para PROJECT_2 e a proteção contra a exfiltração de dados estiver desativada, tem de criar uma política de entrada em PROJECT_2 e uma política de saída em PROJECT_1. No entanto, os pacotes de resposta são excluídos da aplicação de políticas, pelo que não precisa de políticas adicionais.

Siga os passos seguintes para criar uma nova regra de firewall e permitir o tráfego de saída de cargas de trabalho num projeto:

1. Na consola do GDC do projeto que está a configurar, aceda a Rede > Firewall no menu de navegação para abrir a página Firewall.
2. Clique em Criar na barra de ações para começar a criar uma nova regra de firewall.

3. Na página Detalhes da regra de firewall, preencha as seguintes informações:

   1. No campo Nome, introduza um nome válido para a regra de firewall.
   2. Na secção Direção do tráfego, selecione Saída para indicar que esta regra de firewall está a controlar o tráfego de saída.
   3. Na secção Segmentar, selecione uma das seguintes opções:
      • Todas as cargas de trabalho do utilizador: permitem ligações das cargas de trabalho do projeto que está a configurar.
      • Serviço: indica que esta regra de firewall destina-se a um serviço específico no projeto que está a configurar.
   4. Se o seu alvo for um serviço de projeto, selecione o nome do serviço na lista de serviços disponíveis no menu pendente Serviço.
   5. Na secção Para, selecione uma das seguintes opções:
      • Todos os projetos: permitem ligações a cargas de trabalho em todos os projetos da mesma organização.
      • Outro projeto e Todas as cargas de trabalho do utilizador: permitem ligações a cargas de trabalho noutro projeto da mesma organização.
   6. Se quiser transferir cargas de trabalho apenas para outro projeto, selecione um projeto ao qual possa aceder a partir da lista de projetos no menu pendente ID do projeto.
   7. Se o destino for todas as cargas de trabalho do utilizador, selecione uma das seguintes opções na secção Protocolos e portas:
      • Permitir tudo: permitir ligações através de qualquer protocolo ou porta.
      • Protocolos e portas especificados: permitem ligações que usam apenas os protocolos e as portas que especificar nos campos correspondentes para a regra da firewall de saída.

4. Na página Detalhes da regra de firewall, clique em Criar.

Permitiu ligações a outras cargas de trabalho do projeto na mesma organização. Depois de criar a regra de firewall, esta fica visível numa tabela na página Firewall.

Crie uma política entre projetos ao nível da carga de trabalho

As políticas de rede ao nível da carga de trabalho oferecem um controlo detalhado sobre a comunicação entre cargas de trabalho individuais em vários projetos. Esta granularidade permite um controlo mais rigoroso do acesso à rede, melhorando a segurança e a utilização de recursos.

Crie uma política entre projetos ao nível da carga de trabalho de entrada

• Para criar uma política entre projetos ao nível da carga de trabalho de entrada, crie e aplique o seguinte recurso personalizado:

  kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
  apiVersion: networking.global.gdc.goog/v1
  kind: ProjectNetworkPolicy
  metadata:
   namespace: PROJECT_1
   name: allow-cross-project-inbound-traffic-from-target-to-subject
  spec:
   policyType: Ingress
   subject:
     subjectType: UserWorkload
     workloadSelector:
       matchLabels:
         SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
   ingress:
   - from:
     - projectSelector:
         projects:
           matchNames:
           - PROJECT_2
         workloads:
           matchLabels:
             TARGET_LABEL_KEY: TARGET_LABEL_VALUE
  EOF
  

  Substitua o seguinte:

  • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.
  • PROJECT_1: o nome do projeto que está a receber o tráfego.
  • PROJECT_2: o nome do projeto de onde o tráfego está a ser gerado.
  • SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho de origem. Por exemplo, app, tier ou role.
  • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Especifica que cargas de trabalho são a origem do tráfego permitido. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com a etiqueta app: backend são a origem do tráfego.
  • TARGET_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho de destino.
  • TARGET_LABEL_VALUE: o valor associado ao TARGET_LABEL_KEY. Especifica que cargas de trabalho são o destino do tráfego permitido.

Crie uma política entre projetos ao nível da carga de trabalho de saída

• Para criar uma política entre projetos ao nível da carga de trabalho de saída, crie e aplique o seguinte recurso personalizado:

  kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
  apiVersion: networking.global.gdc.goog/v1
  kind: ProjectNetworkPolicy
  metadata:
    namespace: PROJECT_1
    name: allow-cross-project-outbound-traffic-to-subject-from-target
  spec:
    policyType: Egress
    subject:
      subjectType: UserWorkload
      workloadSelector:
        matchLabels:
          SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
    egress:
    - to:
      - projectSelector:
          projects:
            matchNames:
            - PROJECT_2
          workloads:
            matchLabels:
              TARGET_LABEL_KEY: TARGET_LABEL_VALUE
  EOF
  

  Substitua o seguinte:

  • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.
  • PROJECT_1: o nome do projeto que está a enviar o tráfego.
  • PROJECT_2: o nome do projeto que está a receber o tráfego.
  • SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho de origem. Por exemplo, app, tier ou role.
  • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Especifica que cargas de trabalho são a origem do tráfego permitido. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com a etiqueta app: backend são a origem do tráfego.
  • TARGET_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho de destino.
  • TARGET_LABEL_VALUE: o valor associado ao TARGET_LABEL_KEY. Especifica que cargas de trabalho são o destino do tráfego permitido.

Crie uma política entre projetos ao nível da carga de trabalho de zona única

As políticas de rede ao nível da carga de trabalho podem aplicar o PNP ao longo de uma única zona. Podem ser adicionadas etiquetas específicas a cargas de trabalho numa única zona, o que lhe permite controlar a comunicação entre cargas de trabalho individuais num projeto ou em projetos diferentes para essa zona.

Crie uma política entre projetos ao nível da carga de trabalho de entrada de zona única

1. Para criar uma política entre projetos ao nível da carga de trabalho de entrada de uma única zona, crie e aplique o seguinte recurso personalizado:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT_1
     name: allow-single-zone-cross-project-inbound-traffic-from-target-to-subject
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       workloadSelector:
         matchLabels:
           SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
           ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - PROJECT_2
           workloads:
             matchLabels:
               TARGET_LABEL_KEY: TARGET_LABEL_VALUE
               ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
   EOF
   

   Nota: os recursos têm de ter etiquetas exatamente correspondentes. Para garantir que esta política é aplicada numa única zona, as cargas de trabalho de origem e de destino têm de ter a mesma etiqueta de zona.

   Substitua o seguinte:

   • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.
   • PROJECT_1: o nome do projeto que está a receber o tráfego.
   • PROJECT_2: o nome do projeto de onde o tráfego está a ser gerado.
   • SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho de origem. Por exemplo, app, tier ou role.
   • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Especifica que cargas de trabalho são a origem do tráfego permitido. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com a etiqueta app: backend são a origem do tráfego.
   • TARGET_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho de destino.
   • TARGET_LABEL_VALUE: o valor associado ao TARGET_LABEL_KEY. Especifica que cargas de trabalho são o destino do tráfego permitido.
   • ZONE_SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar a zona de origem. Por exemplo, zone ou region.
   • ZONE_SUBJECT_LABEL_VALUE: o valor associado ao ZONE_SUBJECT_LABEL_KEY. Especifica que zona é a origem do tráfego permitido. Por exemplo, se ZONE_SUBJECT_LABEL_KEY for zone e ZONE_SUBJECT_LABEL_VALUE for us-central1-a, as cargas de trabalho com a etiqueta zone: us-central1-a são a origem do tráfego.
   • ZONE_TARGET_LABEL_KEY: a chave da etiqueta usada para selecionar a zona de destino.
   • ZONE_TARGET_LABEL_VALUE: o valor associado ao ZONE_TARGET_LABEL_KEY. Especifica qual a zona que é o destino do tráfego permitido.

Crie uma política entre projetos ao nível da carga de trabalho de saída de uma única zona

• Para criar uma política entre projetos ao nível da carga de trabalho de saída de uma única zona, crie e aplique o seguinte recurso personalizado:

  kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
  apiVersion: networking.global.gdc.goog/v1
  kind: ProjectNetworkPolicy
  metadata:
    namespace: PROJECT_1
    name: allow-single-zone-cross-project-outbound-traffic-to-subject-from-target
  spec:
    policyType: Egress
    subject:
      subjectType: UserWorkload
      workloadSelector:
        matchLabels:
          SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
          ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
    egress:
    - to:
      - projectSelector:
          projects:
            matchNames:
            - PROJECT_2
          workloads:
            matchLabels:
              TARGET_LABEL_KEY: TARGET_LABEL_VALUE
              ZONE_TARGET_LABEL_KEY: ZONE_TARGET_LABEL_VALUE
  EOF
  

  Nota: os recursos têm de ter etiquetas exatamente correspondentes. Para garantir que esta política é aplicada numa única zona, as cargas de trabalho de origem e de destino têm de ter a mesma etiqueta de zona.

  Substitua o seguinte:

  • GLOBAL_API_SERVER: o caminho kubeconfig do servidor da API global. Para mais informações, consulte o artigo Servidores de API globais e zonais. Se ainda não gerou um ficheiro kubeconfig para o servidor da API, consulte o artigo Iniciar sessão para ver detalhes.
  • PROJECT_1: o nome do projeto que está a enviar o tráfego.
  • PROJECT_2: o nome do projeto que está a receber o tráfego.
  • SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho de origem. Por exemplo, app, tier ou role.
  • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Especifica que cargas de trabalho são a origem do tráfego permitido. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com a etiqueta app: backend são a origem do tráfego.
  • TARGET_LABEL_KEY: a chave da etiqueta usada para selecionar as cargas de trabalho de destino.
  • TARGET_LABEL_VALUE: o valor associado ao TARGET_LABEL_KEY. Especifica que cargas de trabalho são o destino do tráfego permitido.
  • ZONE_SUBJECT_LABEL_KEY: a chave da etiqueta usada para selecionar a zona de origem. Por exemplo, zone ou region.
  • ZONE_SUBJECT_LABEL_VALUE: o valor associado ao ZONE_SUBJECT_LABEL_KEY. Especifica que zona é a origem do tráfego permitido. Por exemplo, se ZONE_SUBJECT_LABEL_KEY for zone e ZONE_SUBJECT_LABEL_VALUE for us-central1-a, as cargas de trabalho com a etiqueta zone: us-central1-a são a origem do tráfego.
  • ZONE_TARGET_LABEL_KEY: a chave da etiqueta usada para selecionar a zona de destino.
  • ZONE_TARGET_LABEL_VALUE: o valor associado ao ZONE_TARGET_LABEL_KEY. Especifica qual a zona que é o destino do tráfego permitido.