Criar políticas de rede entre projetos

Nesta página, você encontra instruções para configurar políticas de rede de tráfego entre projetos no Google Distributed Cloud (GDC) com isolamento físico.

O tráfego entre projetos se refere à comunicação entre serviços e cargas de trabalho de diferentes namespaces de projetos, mas dentro da mesma organização.

Por padrão, os serviços e as cargas de trabalho em um projeto são isolados de serviços e cargas de trabalho externos. No entanto, serviços e cargas de trabalho de namespaces de projetos diferentes e dentro da mesma organização podem se comunicar entre si aplicando políticas de rede de tráfego entre projetos.

Por padrão, essas políticas são aplicadas globalmente em todas as zonas. Para mais informações sobre recursos globais em um universo do GDC, consulte Visão geral de várias zonas.

Se for necessário aplicar o tráfego entre projetos em uma única zona, consulte Criar uma política entre projetos no 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, você precisa ter o seguinte:

  • Os papéis necessários de identidade e acesso. Para gerenciar políticas de um projeto específico, você precisa da função project-networkpolicy-admin. Para ambientes multizona em que é necessário gerenciar políticas que abrangem todas as zonas, você precisa da função global-project-networkpolicy-admin. Para mais informações, consulte Preparar papéis predefinidos e acesso.
  • Um projeto atual. Para mais informações, consulte Criar um projeto.

Criar uma política entre projetos

É possível definir políticas de tráfego de entrada ou saída entre projetos para gerenciar a comunicação entre eles.

Criar uma política de entrada entre projetos

Para que cargas de trabalho ou serviços de um projeto permitam conexões de outras cargas de trabalho em outro projeto da sua organização, é necessário configurar uma regra de firewall de entrada para permitir o tráfego de entrada de outras cargas de trabalho do projeto.

Essa política se aplica a todas as zonas da sua organização.

Siga as etapas abaixo para criar uma regra de firewall e permitir o tráfego de entrada de cargas de trabalho em outro projeto:

Console

  1. No console do GDC do projeto que você está configurando, acesse 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 regra de firewall.

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

    1. No campo Nome, insira um nome válido para a regra de firewall.
    2. Na seção Direção do tráfego, selecione Entrada para permitir o tráfego de entrada de cargas de trabalho em outros projetos.
    3. Na seção Segmentar, selecione uma das seguintes opções:
      • Todas as cargas de trabalho do usuário:permite conexões com as cargas de trabalho do projeto que você está configurando.
      • Serviço:indica que essa regra de firewall tem como destino um serviço específico no projeto que você está configurando.
    4. Se o destino for um serviço do projeto, selecione o nome dele no menu suspenso Serviço.
    5. Na seção De, selecione uma das seguintes opções:
      • Todos os projetos:permite conexões de cargas de trabalho em todos os projetos da mesma organização.
      • Outro projeto e Todas as cargas de trabalho do usuário:permitem conexões de cargas de trabalho em outro projeto da mesma organização.
    6. Se você quiser transferir cargas de trabalho apenas de outro projeto, selecione um projeto a que você tenha acesso na lista de projetos do menu suspenso ID do projeto.
    7. Se o destino for todas as cargas de trabalho do usuário, selecione uma das seguintes opções na seção Protocolos e portas:
      • Permitir tudo:permite conexões usando qualquer protocolo ou porta.
      • Protocolos e portas especificados:permitem conexões usando apenas os protocolos e portas especificados nos campos correspondentes da regra de firewall de entrada.

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

Agora você permitiu conexões de outras cargas de trabalho de projetos na mesma organização. Depois de criar a regra de firewall, ela fica visível em uma tabela na página Firewall.

API

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, 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 do kubeconfig do servidor da API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.

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, é preciso ter 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

Agora, as conexões são permitidas de e para PROJECT_1 e PROJECT_2.

Criar uma política de saída entre projetos

Quando você concede uma política de tráfego de entrada entre projetos para permitir que cargas de trabalho em um projeto aceitem conexões de cargas de trabalho em outro projeto, essa ação 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 no projeto original.

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

Siga estas etapas para criar uma regra de firewall e permitir o tráfego de saída de cargas de trabalho em um projeto:

  1. No console do GDC do projeto que você está configurando, acesse 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 regra de firewall.

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

    1. No campo Nome, insira um nome válido para a regra de firewall.
    2. Na seção Direção do tráfego, selecione Saída para indicar que essa regra de firewall está controlando o tráfego de saída.
    3. Na seção Segmentar, selecione uma das seguintes opções:
      • Todas as cargas de trabalho do usuário:permite conexões das cargas de trabalho do projeto que você está configurando.
      • Serviço:indica que essa regra de firewall tem como destino um serviço específico no projeto que você está configurando.
    4. Se o destino for um serviço do projeto, selecione o nome dele no menu suspenso Serviço.
    5. Na seção Para, selecione uma das seguintes opções:
      • Todos os projetos:permite conexões com cargas de trabalho em todos os projetos da mesma organização.
      • Outro projeto e Todas as cargas de trabalho do usuário:permitem conexões com cargas de trabalho em outro projeto da mesma organização.
    6. Se você quiser transferir cargas de trabalho apenas para outro projeto, selecione um projeto a que você tenha acesso na lista de projetos do menu suspenso ID do projeto.
    7. Se o destino for todas as cargas de trabalho do usuário, selecione uma das seguintes opções na seção Protocolos e portas:
      • Permitir tudo:permite conexões usando qualquer protocolo ou porta.
      • Protocolos e portas especificados:permite conexões usando apenas os protocolos e portas especificados nos campos correspondentes da regra de firewall de saída.

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

Agora você permitiu conexões com outras cargas de trabalho de projetos na mesma organização. Depois de criar a regra de firewall, ela fica visível em uma tabela na página Firewall.

Criar uma política entre projetos no nível da carga de trabalho

As políticas de rede no nível da carga de trabalho oferecem controle granular sobre a comunicação entre cargas de trabalho individuais em vários projetos. Essa granularidade permite um controle mais rígido do acesso à rede, melhorando a segurança e o uso de recursos.

Criar uma política de entrada entre projetos no nível da carga de trabalho

  • Para criar uma política entre projetos no 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:

    • GLOBAL_API_SERVER: o caminho do kubeconfig do servidor de API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
    • PROJECT_1: o nome do projeto que está recebendo o tráfego.
    • PROJECT_2: o nome do projeto de onde o tráfego está vindo.
    • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho de origem. Por exemplo, app, tier ou role.
    • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Ele especifica quais 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 o rótulo app: backend serão a origem do tráfego.
    • TARGET_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho de destino.
    • TARGET_LABEL_VALUE: o valor associado ao TARGET_LABEL_KEY. Ele especifica quais cargas de trabalho são o destino do tráfego permitido.

Criar uma política de saída entre projetos no nível da carga de trabalho

  • Para criar uma política de saída entre projetos no nível da carga de trabalho, 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:

    • GLOBAL_API_SERVER: o caminho do kubeconfig do servidor de API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
    • PROJECT_1: o nome do projeto que está enviando o tráfego.
    • PROJECT_2: o nome do projeto que está recebendo o tráfego.
    • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho de origem. Por exemplo, app, tier ou role.
    • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Ele especifica quais 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 o rótulo app: backend serão a origem do tráfego.
    • TARGET_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho de destino.
    • TARGET_LABEL_VALUE: o valor associado ao TARGET_LABEL_KEY. Ele especifica quais cargas de trabalho são o destino do tráfego permitido.

Criar uma política entre projetos no nível da carga de trabalho de zona única

As políticas de rede no nível da carga de trabalho podem aplicar o PNP em uma única zona. Rótulos específicos podem ser adicionados a cargas de trabalho em uma única zona, permitindo controlar a comunicação entre cargas de trabalho individuais em um projeto ou em projetos diferentes para essa zona.

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

  1. Para criar uma política entre projetos no nível da carga de trabalho de entrada de zona única, 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

    Substitua:

    • GLOBAL_API_SERVER: o caminho do kubeconfig do servidor de API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
    • PROJECT_1: o nome do projeto que está recebendo o tráfego.
    • PROJECT_2: o nome do projeto de onde o tráfego está vindo.
    • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho de origem. Por exemplo, app, tier ou role.
    • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Ele especifica quais 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 o rótulo app: backend serão a origem do tráfego.
    • TARGET_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho de destino.
    • TARGET_LABEL_VALUE: o valor associado ao TARGET_LABEL_KEY. Ele especifica quais cargas de trabalho são o destino do tráfego permitido.
    • ZONE_SUBJECT_LABEL_KEY: a chave do rótulo usada para selecionar a zona de origem. Por exemplo, zone ou region.
    • ZONE_SUBJECT_LABEL_VALUE: o valor associado ao ZONE_SUBJECT_LABEL_KEY. Ela especifica qual 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 o rótulo zone: us-central1-a serão a origem do tráfego.
    • ZONE_TARGET_LABEL_KEY: a chave do rótulo usado para selecionar a zona de destino.
    • ZONE_TARGET_LABEL_VALUE: o valor associado ao ZONE_TARGET_LABEL_KEY. Ela especifica qual zona é o destino do tráfego permitido.

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

  • Para criar uma política entre projetos no 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

    Substitua:

    • GLOBAL_API_SERVER: o caminho do kubeconfig do servidor de API global. Para mais informações, consulte Servidores de API globais e zonais. Se você ainda não gerou um arquivo kubeconfig para o servidor da API, consulte Fazer login para mais detalhes.
    • PROJECT_1: o nome do projeto que está enviando o tráfego.
    • PROJECT_2: o nome do projeto que está recebendo o tráfego.
    • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho de origem. Por exemplo, app, tier ou role.
    • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Ele especifica quais 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 o rótulo app: backend serão a origem do tráfego.
    • TARGET_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho de destino.
    • TARGET_LABEL_VALUE: o valor associado ao TARGET_LABEL_KEY. Ele especifica quais cargas de trabalho são o destino do tráfego permitido.
    • ZONE_SUBJECT_LABEL_KEY: a chave do rótulo usada para selecionar a zona de origem. Por exemplo, zone ou region.
    • ZONE_SUBJECT_LABEL_VALUE: o valor associado ao ZONE_SUBJECT_LABEL_KEY. Ela especifica qual 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 o rótulo zone: us-central1-a serão a origem do tráfego.
    • ZONE_TARGET_LABEL_KEY: a chave do rótulo usado para selecionar a zona de destino.
    • ZONE_TARGET_LABEL_VALUE: o valor associado ao ZONE_TARGET_LABEL_KEY. Ela especifica qual zona é o destino do tráfego permitido.