Criar políticas de rede intraprojeto

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

As políticas de rede do projeto definem regras de entrada ou saída. É possível definir políticas que permitem a comunicação dentro de projetos, entre projetos e com endereços IP externo.

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 intraprojeto em uma única zona, consulte Criar uma política intraprojeto no nível da carga de trabalho de uma única zona.

Antes de começar

Para configurar políticas de rede de tráfego intraprojeto, 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

Para o tráfego em um projeto, o GDC aplica uma política de rede predefinida do projeto, a política intraprojeto, a cada projeto por padrão. Por padrão, as cargas de trabalho em um namespace de projeto podem se comunicar entre si sem expor nada a recursos externos.

Por padrão, não há política de saída, então o tráfego de saída é permitido para todo o tráfego intraprojeto. No entanto, quando você define uma única política de saída, apenas o tráfego especificado por ela é permitido.

Observação: as políticas definidas nesta seção se aplicam a clusters compartilhados e padrão.

Criar uma política de entrada entre projetos

Ao criar um projeto, você cria implicitamente um recurso ProjectNetworkPolicy base padrão que permite 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 a política padrão, mas isso vai negar a comunicação entre projetos para todos os serviços e cargas de trabalho no projeto. Para remover a política, use o comando kubectl delete:

kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT

Para adicionar a política padrão novamente, aplique o seguinte manifesto:

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: base-policy-allow-intra-project-traffic
spec:
  policyType: Ingress
  ingress:
  - from:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT
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: o nome do projeto.

Criar uma política de saída entre projetos

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

kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ProjectNetworkPolicy
metadata:
  namespace: PROJECT
  name: allow-intra-project-outbound-traffic
spec:
  policyType: Egress
  egress:
  - to:
    - projectSelector:
        projects:
          matchNames:
          - PROJECT
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: o nome do projeto.

Criar uma política intraprojeto 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 um projeto. 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 no nível da carga de trabalho intraprojeto

Ao criar um projeto, você cria implicitamente um recurso ProjectNetworkPolicy básico padrão que permite a comunicação entre todas as cargas de trabalho dentro do projeto. Essa política permite o tráfego de entrada de outras cargas de trabalho no mesmo projeto.

Para criar uma política de entrada no nível da carga de trabalho entre projetos, primeiro é necessário excluir a política de base padrão. Caso contrário, pode ocorrer um comportamento inesperado.

1. Para excluir a política de base padrão, execute o seguinte comando:

   kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT
   

2. Para criar uma política de entrada no nível da carga de trabalho intraprojeto, 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
     name: allow-workload-level-intra-project-inbound-traffic
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - PROJECT
           workloadSelector:
             labelSelector:
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_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: o nome do projeto.
   • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
   • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com o rótulo app: backend vão receber o tráfego.
   • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
   • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.
   Aviso: ao fazer referência a rótulos de VM nos campos workloadSelector ou workloads, adicione o prefixo user-label.gpc.gke.io/ à chave do rótulo. Por exemplo, se você atribuir o rótulo app: backend a uma VM, especifique-o como user-label.gpc.gke.io/app: backend para corresponder à carga de trabalho. Esse prefixo é específico para VMs e não se aplica a outras cargas de trabalho.

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

• Para criar uma política de saída no nível da carga de trabalho entre projetos, 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
    name: allow-workload-level-intra-project-outbound-traffic
  spec:
    policyType: Egress
    subject:
      subjectType: UserWorkload
      userWorkloadSelector:
        labelSelector:
          workloads
            matchLabels:
              SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
    egress:
    - to:
      - projectSelector:
          projects:
            matchNames:
            - PROJECT
          workloadSelector:
            labelSelector:
              workloads:
                matchLabels:
                  PEER_LABEL_KEY: PEER_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: o nome do projeto.
  • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
  • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com o rótulo app: backend estarão enviando o tráfego.
  • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
  • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.
  Aviso: ao fazer referência a rótulos de VM nos campos workloadSelector ou workloads, adicione o prefixo user-label.gpc.gke.io/ à chave do rótulo. Por exemplo, se você atribuir o rótulo app: backend a uma VM, especifique-o como user-label.gpc.gke.io/app: backend para corresponder à carga de trabalho. Esse prefixo é específico para VMs e não se aplica a outras cargas de trabalho.

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

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 de entrada de zona única no nível da carga de trabalho intraprojeto

Ao criar um projeto, você cria implicitamente um recurso ProjectNetworkPolicy básico padrão que permite a comunicação entre todas as cargas de trabalho dentro do projeto. Essa política permite o tráfego de entrada de outras cargas de trabalho no mesmo projeto.

Para criar uma política de entrada de zona única no nível da carga de trabalho entre projetos, primeiro exclua a política básica padrão. Caso contrário, pode ocorrer um comportamento inesperado.

1. Para excluir a política de base padrão, execute o seguinte comando:

   kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT
   

2. Para criar uma política de rede de tráfego intraprojeto no 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
     name: allow-single-zone-intra-project-inbound-traffic
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
               ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - PROJECT
           workloadSelector:
             labelSelector:
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_LABEL_VALUE
                   ZONE_PEER_LABEL_KEY: ZONE_PEER_LABEL_VALUE
   EOF
   

   Observação: os recursos precisam ter rótulos correspondentes. Para garantir que essa política seja aplicada em uma única zona, as cargas de trabalho de assunto e de peer precisam ter o mesmo rótulo de zona.

   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: o nome do projeto.
   • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
   • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com o rótulo app: backend vão receber o tráfego.
   • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
   • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.
   • ZONE_SUBJECT_LABEL_KEY: a chave do rótulo usada para selecionar a zona de assunto. Por exemplo, zone ou region. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
   • ZONE_SUBJECT_LABEL_VALUE: o valor associado ao ZONE_SUBJECT_LABEL_KEY. 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 vão receber o tráfego.
   • ZONE_PEER_LABEL_KEY: a chave do rótulo usado para selecionar a zona associada ao peer. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
   • ZONE_PEER_LABEL_VALUE: o valor associado ao ZONE_PEER_LABEL_KEY.
   Aviso: ao fazer referência a rótulos de VM nos campos workloadSelector ou workloads, adicione o prefixo user-label.gpc.gke.io/ à chave do rótulo. Por exemplo, se você atribuir o rótulo app: backend a uma VM, especifique-o como user-label.gpc.gke.io/app: backend para corresponder à carga de trabalho. Esse prefixo é específico para VMs e não se aplica a outras cargas de trabalho.

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

• Para criar uma política de saída no nível da carga de trabalho intraprojeto 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
    name: allow-single-zone-intra-project-outbound-traffic
  spec:
    policyType: Egress
    subject:
      subjectType: UserWorkload
      userWorkloadSelector:
        labelSelector:
          workloads:
            matchLabels:
              SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
              ZONE_SUBJECT_LABEL_KEY: ZONE_SUBJECT_LABEL_VALUE
    egress:
    - to:
      - projectSelector:
          projects:
            matchNames:
            - PROJECT
          workloadSelector:
            labelSelector:
              workloads:
                matchLabels:
                  PEER_LABEL_KEY: PEER_LABEL_VALUE
                  ZONE_PEER_LABEL_KEY: ZONE_PEER_LABEL_VALUE
  EOF
  

  Observação: os recursos precisam ter rótulos correspondentes. Para garantir que essa política seja aplicada em uma única zona, as cargas de trabalho de assunto e de peer precisam ter o mesmo rótulo de zona.

  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: o nome do projeto.
  • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
  • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com o rótulo app: backend vão receber o tráfego.
  • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
  • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.
  • ZONE_SUBJECT_LABEL_KEY: a chave do rótulo usada para selecionar a zona de assunto. Por exemplo, zone ou region. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
  • ZONE_SUBJECT_LABEL_VALUE: o valor associado ao ZONE_SUBJECT_LABEL_KEY. 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 vão receber o tráfego.
  • ZONE_PEER_LABEL_KEY: a chave do rótulo usado para selecionar a zona associada ao peer. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
  • ZONE_PEER_LABEL_VALUE: o valor associado ao ZONE_PEER_LABEL_KEY.
  Aviso: ao fazer referência a rótulos de VM nos campos workloadSelector ou workloads, adicione o prefixo user-label.gpc.gke.io/ à chave do rótulo. Por exemplo, se você atribuir o rótulo app: backend a uma VM, especifique-o como user-label.gpc.gke.io/app: backend para corresponder à carga de trabalho. Esse prefixo é específico para VMs e não se aplica a outras cargas de trabalho.

Criar uma política intraprojeto para clusters padrão

Os clusters padrão são clusters do Kubernetes com escopo de projeto que oferecem mais controle, flexibilidade e permissões de administrador do cluster. Quando você cria uma política intraprojeto, ela é herdada pelos clusters padrão por padrão. Essa política permite toda a comunicação nos clusters padrão que residem no mesmo projeto.

Criar uma política de entrada intraprojeto para clusters padrão

Ao criar um projeto, você cria implicitamente um recurso ProjectNetworkPolicy básico padrão que permite a comunicação entre todas as cargas de trabalho dentro do projeto. Essa política permite o tráfego de entrada de outras cargas de trabalho no mesmo projeto e também a comunicação entre todas as cargas de trabalho nos clusters padrão dentro do projeto.

Para criar uma política de entrada intraprojeto para clusters padrão, primeiro exclua a política de base padrão. Caso contrário, pode ocorrer um comportamento inesperado.

1. Para excluir a política de base padrão, execute o seguinte comando:

   kubectl --kubeconfig GLOBAL_API_SERVER delete pnp base-policy-allow-intra-project-traffic -n PROJECT
   

   Para adicionar a política padrão novamente, aplique o seguinte manifesto:

   kubectl --kubeconfig GLOBAL_API_SERVER apply -f - <<EOF
   apiVersion: networking.global.gdc.goog/v1
   kind: ProjectNetworkPolicy
   metadata:
     namespace: PROJECT
     name: base-policy-allow-intra-project-traffic
   spec:
     policyType: Ingress
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - PROJECT
   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: o nome do projeto.

2. Para criar uma política de pod para pod intra-cluster de entrada em clusters padrão, 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: STANDARD_CLUSTER_PROJECT
     name: allow-ingress-from-intra-cluster-traffic
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           clusters:
             matchLabels:
               kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
           namespaces:
             matchLabels:
               kubernetes.io/metadata.name: SUBJECT_NAMESPACE
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - projectSelector:
           projects:
             matchNames:
             - STANDARD_CLUSTER_PROJECT
           workloadSelector:
             labelSelector:
               clusters:
                 matchLabels:
                   kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
               namespaces:
                 matchLabels:
                   kubernetes.io/metadata.name: PEER_NAMESPACE
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_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.
   • STANDARD_CLUSTER_PROJECT: o nome do projeto do cluster padrão.
   • STANDARD_CLUSTER_NAME: o nome do cluster padrão.
   • SUBJECT_NAMESPACE: o namespace do assunto no cluster padrão.
   • PEER_NAMESPACE: o namespace do peer no cluster padrão.
   • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
   • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com o rótulo app: backend vão receber o tráfego.
   • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
   • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.
   Aviso: ao fazer referência a rótulos de VM nos campos workloadSelector ou workloads, adicione o prefixo user-label.gpc.gke.io/ à chave do rótulo. Por exemplo, se você atribuir o rótulo app: backend a uma VM, especifique-o como user-label.gpc.gke.io/app: backend para corresponder à carga de trabalho. Esse prefixo é específico para VMs e não se aplica a outras cargas de trabalho.

3. Para criar uma política de nó para pod de entrada intracluster em clusters padrão, 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: STANDARD_CLUSTER_PROJECT
     name: allow-ingress-from-node-to-pod-traffic
   spec:
     policyType: Ingress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           clusters:
             matchLabels:
               kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
           namespaces:
             matchLabels:
               kubernetes.io/metadata.name: SUBJECT_NAMESPACE
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     ingress:
     - from:
       - ipBlocks:
         - cidr: NODE_IP
       ports:
       - protocol: TCP
         port: PORT
   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.
   • STANDARD_CLUSTER_PROJECT: o nome do projeto do cluster padrão.
   • STANDARD_CLUSTER_NAME: o nome do cluster padrão.
   • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
   • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com o rótulo app: backend vão receber o tráfego.
   • NODE_IP: o endereço IP do nó.
   • PORT: a porta na carga de trabalho em questão em que o tráfego é permitido.
   Aviso: ao fazer referência a rótulos de VM nos campos workloadSelector ou workloads, adicione o prefixo user-label.gpc.gke.io/ à chave do rótulo. Por exemplo, se você atribuir o rótulo app: backend a uma VM, especifique-o como user-label.gpc.gke.io/app: backend para corresponder à carga de trabalho. Esse prefixo é específico para VMs e não se aplica a outras cargas de trabalho.

Criar uma política de saída intraprojeto para clusters padrão

1. Para criar uma política de saída de pod para pod intra-cluster em clusters padrão, 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: STANDARD_CLUSTER_PROJECT
     name: allow-egress-to-intra-cluster-traffic
   spec:
     policyType: Egress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           clusters:
             matchLabels:
               kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
           namespaces:
             matchLabels:
               kubernetes.io/metadata.name: SUBJECT_NAMESPACE
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     egress:
     - to:
       - projectSelector:
           projects:
             matchNames:
             - STANDARD_CLUSTER_PROJECT
           workloadSelector:
             labelSelector:
               clusters:
                 matchLabels:
                   kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
               namespaces:
                 matchLabels:
                   kubernetes.io/metadata.name: PEER_NAMESPACE
               workloads:
                 matchLabels:
                   PEER_LABEL_KEY: PEER_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.
   • STANDARD_CLUSTER_PROJECT: o nome do projeto do cluster padrão.
   • STANDARD_CLUSTER_NAME: o nome do cluster padrão.
   • SUBJECT_NAMESPACE: o namespace do assunto no cluster padrão.
   • PEER_NAMESPACE: o namespace do peer no cluster padrão.
   • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
   • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com o rótulo app: backend estarão enviando o tráfego.
   • PEER_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho do mesmo nível. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
   • PEER_LABEL_VALUE: o valor associado ao PEER_LABEL_KEY.
   Aviso: ao fazer referência a rótulos de VM nos campos workloadSelector ou workloads, adicione o prefixo user-label.gpc.gke.io/ à chave do rótulo. Por exemplo, se você atribuir o rótulo app: backend a uma VM, especifique-o como user-label.gpc.gke.io/app: backend para corresponder à carga de trabalho. Esse prefixo é específico para VMs e não se aplica a outras cargas de trabalho.
   1. Para criar uma política de saída de pod para nó intra-cluster em clusters padrão, 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: STANDARD_CLUSTER_PROJECT
     name: allow-egress-from-pod-to-node-traffic
   spec:
     policyType: Egress
     subject:
       subjectType: UserWorkload
       userWorkloadSelector:
         labelSelector:
           clusters:
             matchLabels:
               kubernetes.io/metadata.name: STANDARD_CLUSTER_NAME
           namespaces:
             matchLabels:
               kubernetes.io/metadata.name: SUBJECT_NAMESPACE
           workloads:
             matchLabels:
               SUBJECT_LABEL_KEY: SUBJECT_LABEL_VALUE
     egress:
     - to:
       - ipBlocks:
         - cidr: NODE_IP
       ports:
       - protocol: TCP
         port: PORT
   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.
   • STANDARD_CLUSTER_PROJECT: o nome do projeto do cluster padrão.
   • STANDARD_CLUSTER_NAME: o nome do cluster padrão.
   • SUBJECT_LABEL_KEY: a chave do rótulo usado para selecionar as cargas de trabalho em questão. Por exemplo, app, tier ou role. Se você estiver referenciando rótulos de VM, adicione um prefixo a essa chave. Consulte o aviso abaixo desta lista.
   • SUBJECT_LABEL_VALUE: o valor associado ao SUBJECT_LABEL_KEY. Por exemplo, se SUBJECT_LABEL_KEY for app e SUBJECT_LABEL_VALUE for backend, as cargas de trabalho com o rótulo app: backend estarão enviando o tráfego.
   • NODE_IP: o endereço IP do nó.
   • PORT: a porta no IP do nó em que o tráfego é permitido.
   Aviso: ao fazer referência a rótulos de VM nos campos workloadSelector ou workloads, adicione o prefixo user-label.gpc.gke.io/ à chave do rótulo. Por exemplo, se você atribuir o rótulo app: backend a uma VM, especifique-o como user-label.gpc.gke.io/app: backend para corresponder à carga de trabalho. Esse prefixo é específico para VMs e não se aplica a outras cargas de trabalho.