Aplique seletivamente políticas de firewall no GKE

Esta página mostra como aplicar seletivamente políticas de firewall de rede da firewall de próxima geração do Google Cloud no Google Kubernetes Engine (GKE) através de etiquetas. As etiquetas oferecem um controlo mais detalhado para organizar a hierarquia de recursos em comparação com a Cloud de Confiance by S3NS hierarquia de recursos predefinida. As etiquetas também permitem a aplicação condicional de políticas.

Esta página destina-se a especialistas em segurança que pretendam um controlo detalhado das políticas de firewall no GKE. Para saber mais acerca das funções comuns e das tarefas de exemplo que referimos no Cloud de Confiance by S3NS conteúdo, consulte o artigo Funções e tarefas comuns de utilizadores do GKE.

Antes de ler esta página, certifique-se de que conhece os seguintes conceitos:

• Vista geral das etiquetas
• Como usar etiquetas para outros fins, como a gestão de faturação ou políticas de IAM condicionais.

Acerca das etiquetas

As etiquetas são pares de chave-valor que lhe permitem anotar e gerir os seus Cloud de Confiance by S3NS recursos ao nível da organização ou do projeto. Pode usar etiquetas para organizar os seus recursos e aplicar condicionalmente políticas, como firewalls ou políticas de IAM. Pode usar o controlo de acesso do IAM para definir quem pode anexar, criar, atualizar ou eliminar etiquetas.

Para saber mais acerca das etiquetas, consulte a vista geral das etiquetas na documentação do Resource Manager.

Use etiquetas para aplicar políticas de firewall de rede

Pode usar etiquetas para aplicar condicionalmente políticas de firewall de rede globais ou regionais aos seus nós do GKE. Tem de designar a finalidade das etiquetas que quer usar com as políticas de firewall de rede.GCE_FIREWALL Quando aplica etiquetas de finalidade da firewall a clusters ou pools de nós do GKE, o GKE anexa automaticamente essas etiquetas às máquinas virtuais (VMs) do Compute Engine correspondentes.

As etiquetas para políticas de firewall de rede substituem a necessidade de usar etiquetas de rede, que são metadados que qualquer pessoa pode anexar às VMs do Compute Engine subjacentes para a aplicação de regras de firewall da nuvem privada virtual e que não suportam o controlo de acesso da IAM. Se usar etiquetas de rede com regras de firewall da VPC, recomendamos que migre para políticas de firewall de rede e use etiquetas de firewall seguras. Para uma comparação detalhada, consulte o artigo Compare as etiquetas de rede com as etiquetas neste documento.

Etiquetas para o fluxo de trabalho das políticas de firewall de rede

Para usar etiquetas com políticas de firewall de rede no GKE, faça o seguinte:

1. Crie uma etiqueta:

   1. Defina uma chave de etiqueta ao nível da organização ou do projeto, como env.
   2. Defina os valores possíveis das etiquetas para a chave, como dev, staging e prod.

   3. Designe a etiqueta para utilização da política de firewall de rede.

2. Conceder aos utilizadores acesso para interagirem com a etiqueta de firewall.

3. Aplique pares de chave-valor de etiquetas a clusters, conjuntos de nós ou use-os em ComputeClasses personalizados para os aplicar a nós para cargas de trabalho específicas. O GKE anexa automaticamente as etiquetas às VMs do Compute Engine subjacentes para a aplicação da política de firewall.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize a CLI gcloud. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.

Requisitos e limitações

• As etiquetas para políticas de firewall de rede são suportadas na versão 1.28 e posteriores do GKE. Se usar uma versão do GKE anterior à 1.28, use etiquetas de rede com regras de firewall da VPC.
• Os clusters e os conjuntos de nós do GKE não suportam etiquetas criadas com a flag --purpose-data=organization=auto. Para cargas de trabalho do GKE, recomendamos que crie etiquetas com âmbito na sua rede VPC através da flag --purpose-data=network. Para mais informações, consulte Crie etiquetas.
• O cluster do GKE e a etiqueta têm de estar associados à mesma rede de VPC.
• Nos clusters padrão, cada conjunto de nós suporta até cinco etiquetas de firewall anexadas.
• Os clusters do Autopilot suportam até cinco etiquetas de firewall.
• A classe de computação personalizada suporta até cinco etiquetas.
• O GKE rejeita chaves de etiquetas que usam o prefixo gke-managed.
• Tem de criar os pares de chave-valor das etiquetas antes de os poder anexar a clusters ou pools de nós.

Funções e autorizações do IAM

Para receber as autorizações de que precisa para usar etiquetas para políticas de firewall no GKE, peça ao seu administrador que lhe conceda as seguintes funções de IAM:

• Para conceder as autorizações necessárias para etiquetas aos utilizadores e aos agentes de serviço do GKE:
  • Administrador de IAM do projeto (roles/resourcemanager.projectIamAdmin) no seu projeto
  • Administrador da organização (roles/resourcemanager.organizationAdmin) na organização
• Para criar e administrar etiquetas: Administrador de etiquetas (roles/resourcemanager.tagAdmin) na organização ou no projeto
• Para anexar etiquetas a recursos: Utilizador de etiquetas (roles/resourcemanager.tagUser) no projeto

Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

Também pode conseguir as autorizações necessárias através de funções personalizadas ou outras funções predefinidas.

Crie etiquetas

As etiquetas têm de existir para as poder anexar a clusters ou nós. Para criar uma etiqueta, consulte o artigo Use etiquetas para firewalls na documentação do Cloud NGFW.

Por exemplo, para criar uma etiqueta de firewall ao nível do projeto, execute os seguintes comandos:

1. Crie a chave da etiqueta:

   gcloud resource-manager tags keys create TAG_KEY \
       --parent=projects/PROJECT_ID \
       --purpose=GCE_FIREWALL \
       --purpose-data=network=PROJECT_ID/NETWORK_NAME
   

   Substitua o seguinte:

   • TAG_KEY: o nome da chave da etiqueta, como env
   • PROJECT_ID: o ID do seu Cloud de Confiance projeto
   • NETWORK_NAME: o nome da rede VPC que vai usar com a etiqueta

2. Obtenha o ID da chave da etiqueta:

   gcloud resource-manager tags keys describe PROJECT_ID/TAG_KEY \
       --format="value(name)"
   

   A saída é tagKeys/KEY_ID, onde KEY_ID é um ID numérico da chave. Tome nota deste ID para mais tarde.

3. Adicione um valor de etiqueta à chave de etiqueta:

   gcloud resource-manager tags values create TAG_VALUE \
       --parent=tagKeys/KEY_ID
   

   Substitua TAG_VALUE pelo nome de um valor permitido para essa chave de etiqueta, como dev.

Use a sintaxe de etiquetas correta nos comandos da CLI gcloud

Quando se refere a etiquetas através da CLI gcloud, tem de formatar os pares de chave-valor com uma das seguintes sintaxes:

tagKeys/KEY_ID=tagValues/VALUE_ID

ORGANIZATION_ID/TAG_KEY=TAG_VALUE

PROJECT_ID/TAG_KEY=TAG_VALUE

PROJECT_NUMBER/TAG_KEY=TAG_VALUE

Segmente etiquetas com políticas de firewall

Depois de criar etiquetas, pode consultar pares de chave-valor específicos nas regras da política de firewall. Para obter instruções, consulte o artigo Use etiquetas para firewalls.

Conceda autorizações de IAM aos agentes de serviço

Para que o GKE anexe automaticamente etiquetas a novos nós durante eventos de expansão, tem de conceder as funções do IAM correspondentes às contas de serviço geridas pela Google, também denominadas agentes de serviço. Cloud de Confiance

1. Conceda a função de utilizador de etiquetas (roles/resourcemanager.tagUser) ao agente de serviço do Kubernetes Engine:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
       --role=roles/resourcemanager.tagUser \
       --condition=None
   

   Substitua PROJECT_NUMBER pelo Cloud de Confiance número do projeto do cluster. Para encontrar o número do projeto, execute o seguinte comando:

   gcloud projects describe PROJECT_ID --format="value(projectNumber)"
   

2. Conceda a função de administrador de retenções de etiquetas (roles/resourcemanager.tagHoldAdmin) ao agente do serviço do Kubernetes Engine para o par chave-valor da etiqueta:

   gcloud resource-manager tags values add-iam-policy-binding PROJECT_ID/TAG_KEY/TAG_VALUE \
       --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
       --role=roles/resourcemanager.tagHoldAdmin
   

   Esta função permite ao agente do serviço impedir a eliminação de etiquetas se o par de chave-valor ainda estiver a ser usado no GKE.

3. Conceda a função de utilizador da etiqueta (roles/resourcemanager.tagUser) ao agente do serviço das APIs Google:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:PROJECT_NUMBER@cloudservices.s3ns-system.iam.gserviceaccount.com \
       --role=roles/resourcemanager.tagUser \
       --condition=None
   

Conceda funções de IAM adicionais para etiquetas fora do projeto

Para usar etiquetas pertencentes a uma organização ou a um projeto diferente do projeto do cluster, siga estes passos adicionais:

1. Conceda a função de utilizador de etiquetas (roles/resourcemanager.tagUser) ao acesso do agente de serviço do Kubernetes Engine para as etiquetas no recurso principal:

   gcloud resource-manager tags keys add-iam-policy-binding PARENT_RESOURCE/TAG_KEY \
       --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
       --role=roles/resourcemanager.tagUser \
       --condition=None
   

   Substitua o seguinte:

   • PARENT_RESOURCE: o ID do projeto ou o ID da organização do recurso proprietário dessa etiqueta
   • PROJECT_NUMBER: o número do projeto do projeto do cluster

2. Conceda a função de utilizador de etiquetas (roles/resourcemanager.tagUser) ao agente de serviço das APIs Google para as etiquetas no recurso principal:

   gcloud resource-manager tags keys add-iam-policy-binding PARENT_RESOURCE/TAG_KEY \
       --member=serviceAccount:PROJECT_NUMBER@cloudservices.s3ns-system.iam.gserviceaccount.com \
       --role=roles/resourcemanager.tagUser \
       --condition=None
   

3. Conceda a função de administrador de retenções de etiquetas (roles/resourcemanager.tagHoldAdmin) ao agente de serviço do Kubernetes Engine para o par de chave-valor da etiqueta:

   gcloud resource-manager tags values add-iam-policy-binding PARENT_RESOURCE/TAG_KEY/TAG_VALUE \
       --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns-system.iam.gserviceaccount.com \
       --role=roles/resourcemanager.tagHoldAdmin
   

Anexe etiquetas de firewall a clusters do Autopilot

Anexa etiquetas de firewall a clusters do Autopilot ao nível do cluster. O GKE aplica automaticamente estas etiquetas ao nível do cluster a todos os nós.

Anexe etiquetas quando criar um novo cluster do Autopilot

Execute o seguinte comando:

gcloud container clusters create-auto CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

Substitua o seguinte:

• CLUSTER_NAME: o nome do novo cluster.
• LOCATION: a região do Compute Engine do cluster.
• TAG1,TAG2,...: um conjunto de pares de chave-valor separados por vírgulas a anexar. Cada par de chave-valor tem de usar uma sintaxe suportada, conforme descrito na secção Sintaxe de etiquetas nos comandos. Por exemplo, example-project/env=dev,1234567901/team=sre.

Anexe etiquetas a clusters do Autopilot existentes

Execute o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,...

Quando atualiza as etiquetas num cluster, o GKE substitui todas as etiquetas existentes em todos os nós.

Anexe etiquetas de firewall a clusters padrão e conjuntos de nós

O método que usa para anexar etiquetas depende de querer que outros conjuntos de nós no cluster herdem as etiquetas, da seguinte forma:

Anexe etiquetas de firewall a clusters padrão

Pode anexar etiquetas a clusters padrão novos ou existentes. Quando anexa etiquetas a um cluster inteiro, o GKE considera que estas etiquetas estão definidas ao nível do cluster.

Anexe etiquetas a um novo cluster padrão com aprovisionamento automático de nós

O GKE usa etiquetas ao nível do cluster para novos nós aprovisionados automaticamente por predefinição. O conjunto de nós predefinido que o GKE cria no cluster não é aprovisionado automaticamente e não recebe essas etiquetas.

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=TAG1,TAG2,... \
    --enable-autoprovisioning \
    --max-cpu=MAX_CPU \
    --max-memory=MAX_MEMORY

Substitua o seguinte:

• CLUSTER_NAME: o nome do novo cluster
• LOCATION: a região ou a zona do Compute Engine para o cluster
• TAG1,TAG2,...: um conjunto de pares de chave-valor separados por vírgulas a anexar. Cada par de chave-valor tem de usar uma sintaxe suportada, conforme descrito na secção Sintaxe de etiquetas nos comandos. Por exemplo, example-project/env=dev,1234567901/team=sre.
• MAX_CPU: o número máximo de núcleos para o cluster
• MAX_MEMORY: a capacidade máxima de memória do cluster em gigabytes

Anexe etiquetas quando ativar o aprovisionamento automático de nós num cluster existente

O GKE só aplica estas etiquetas a novos conjuntos de nós aprovisionados automaticamente. Os conjuntos de nós existentes retêm todas as etiquetas que tinham antes da atualização.

1. Anexe etiquetas ao cluster:

   gcloud container clusters update CLUSTER_NAME \
       --location=LOCATION \
       --autoprovisioning-resource-manager-tags=TAG1,TAG2,...
   

2. Ative a administração de contas automática de nós no cluster:

   gcloud container clusters update CLUSTER_NAME \
       --location=LOCATION \
       --enable-autoprovisioning \
       --max-cpu=MAX_CPU \
       --max-memory=MAX_MEMORY
   

Anexe etiquetas de firewall a pools de nós

Pode anexar etiquetas a pools de nós novos ou existentes, independentemente de usarem o aprovisionamento automático de nós. O GKE considera estas etiquetas uma definição ao nível do conjunto de nós.

Anexe etiquetas ao conjunto de nós predefinido

O GKE anexa as etiquetas que especificar através da flag --resource-manager-tagsquando criar um cluster ao conjunto de nós predefinido que o GKE cria no cluster.

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

Substitua o seguinte:

• CLUSTER_NAME: o nome do novo cluster
• LOCATION: a região ou a zona do Compute Engine para o cluster
• TAG1,TAG2,...: um conjunto de pares de chave-valor separados por vírgulas a anexar. Cada par de chave-valor tem de usar uma sintaxe suportada, conforme descrito na secção Sintaxe de etiquetas nos comandos. Por exemplo, example-project/env=dev,1234567901/team=sre.

Anexe etiquetas a um novo conjunto de nós

Quando usa a flag --resource-manager-tags durante a criação do conjunto de nós, o GKE anexa as etiquetas que especificar a esse conjunto de nós.

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

Substitua o seguinte:

• NODE_POOL_NAME: o nome do novo node pool
• CLUSTER_NAME: o nome do cluster
• LOCATION: a região ou a zona do Compute Engine do cluster
• TAG1,TAG2,...:um conjunto de pares de chave-valor separados por vírgulas a anexar. Cada par de chave-valor tem de usar uma sintaxe suportada, conforme descrito na secção Sintaxe de etiquetas nos comandos. Por exemplo, example-project/env=dev,1234567901/team=sre.

Anexe etiquetas a um conjunto de nós existente

Quando atualiza as etiquetas num conjunto de nós existente com a flag --resource-manager-tags, o GKE substitui todas as etiquetas existentes nesse conjunto de nós. Pode usar este comando para atualizar as etiquetas nos conjuntos de nós aprovisionados automaticamente.

gcloud container node-pools update NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --resource-manager-tags=TAG1,TAG2,...

Substitua NODE_POOL_NAME pelo nome do conjunto de nós a atualizar.

Ative/desative as definições de aprovisionamento automático em clusters e node pools existentes

Quando atualiza as etiquetas ao nível do cluster, o GKE aplica essas novas etiquetas a todos os node pools novos no cluster e retém as etiquetas anexadas aos node pools existentes.

Quando atualiza os node pools existentes para ativar ou desativar o aprovisionamento automático de nós, considere as seguintes implicações para as etiquetas:

• Quando ativa ou desativa o aprovisionamento automático de nós, o conjunto de nós retém todas as etiquetas existentes. O GKE não substitui estas etiquetas por etiquetas ao nível do cluster, mesmo durante a recriação de nós.
• Se atualizar manualmente as etiquetas em pools de nós específicos, o GKE substitui as etiquetas existentes pelas etiquetas especificadas para esse pool de nós.

Aplique etiquetas a cargas de trabalho com ComputeClasses personalizadas

Pode aplicar etiquetas de firewall a pools de nós específicos em clusters do Autopilot e em clusters Standard que usam o aprovisionamento automático de nós (NAP) através de ComputeClasses personalizadas (CCCs). Uma classe de computação personalizada é um recurso que lhe permite definir uma configuração para um grupo de nós, incluindo a definição das etiquetas do Resource Manager a aplicar aos nós.

Quando implementa uma carga de trabalho que pede um nó com uma etiqueta de classe de computação personalizada específica, o NAP verifica primeiro se já existe um conjunto de nós que corresponda a todos os requisitos da classe de computação personalizada, incluindo as etiquetas do Resource Manager especificadas.

Se não existir um conjunto de nós correspondente, o NAP cria um novo conjunto de nós para a carga de trabalho com a configuração especificada e anexa as etiquetas às VMs do Compute Engine subjacentes. Esta criação automática de pools de nós garante que as cargas de trabalho são executadas em nós com as etiquetas de firewall corretas para a aplicação de políticas.

Crie uma ComputeClass personalizada com etiquetas

1. Para criar um ComputeClass com etiquetas, guarde o seguinte manifesto como my-compute-class.yaml. No campo resourceManagerTags, especifique as chaves e os valores das etiquetas a associar aos conjuntos de nós criados com esta classe.

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: COMPUTE_CLASS_NAME
   spec:
       nodePoolConfig:
         resourceManagerTags:
           - key: "PROJECT_ID/TAG_KEY_1"
             value: "TAG_VALUE_1"
           - key: "ORGANIZATION_ID/TAG_KEY_2"
             value: "TAG_VALUE_2"
           - key: "tagKeys/KEY_ID"
             value: "tagValues/VALUE_ID"
   

   Substitua o seguinte:

   • COMPUTE_CLASS_NAME: o nome da sua classe de computação personalizada, por exemplo, my-custom-class.
   • PROJECT_ID: o ID do seu Cloud de Confiance projeto.
   • TAG_KEY_1: o nome da primeira chave de etiqueta.
   • TAG_VALUE_1: o nome do primeiro valor da etiqueta.
   • ORGANIZATION_ID: o ID numérico da sua Cloud de Confiance organização.
   • TAG_KEY_2: o nome da segunda chave de etiqueta.
   • TAG_VALUE_2: o nome do segundo valor da etiqueta.
   • KEY_ID: o ID numérico de uma chave de etiqueta.
   • VALUE_ID: o ID numérico de um valor de etiqueta.

2. Aplique o manifesto:

   kubectl apply -f my-compute-class.yaml
   

Se especificar uma etiqueta inválida ou se os agentes de serviço do GKE não tiverem as autorizações de IAM necessárias para a etiqueta, o GKE não aprovisiona um conjunto de nós para a sua carga de trabalho, e a carga de trabalho permanece no estado Pending. Para mais informações sobre o erro, consulte o campo Status do recurso ComputeClass.

Para verificar o estado, execute o seguinte comando:

kubectl get cc COMPUTE_CLASS_NAME -o jsonpath='{.status}' | jq .

Substitua COMPUTE_CLASS_NAME pelo nome da sua classe de computação personalizada.

Segmente a classe de computação personalizada na sua carga de trabalho

1. Para segmentar a ComputeClass que criou, guarde o seguinte manifesto como pod-with-ccc.yaml. Este manifesto usa o campo nodeSelector para segmentar a classe de computação.

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-server
   spec:
     nodeSelector:
       cloud.google.com/compute-class: "COMPUTE_CLASS_NAME"
     containers:
       - name: nginx
         image: nginx:latest
   

   Substitua COMPUTE_CLASS_NAME pelo nome da sua classe de computação personalizada, por exemplo, my-custom-class.

2. Aplique o manifesto:

   kubectl apply -f pod-with-ccc.yaml
   

Quando agenda uma carga de trabalho que segmenta uma classe de computação personalizada, o GKE aplica automaticamente uma restrição aos nós criados para essa classe e adiciona uma tolerância correspondente aos pods da sua carga de trabalho, para que apenas os pods que pedem explicitamente a classe sejam agendados nesses nós.

Autorize cargas de trabalho com uma política de admissão de validação (VAP)

Para ajudar a garantir que apenas as cargas de trabalho autorizadas podem ser agendadas em conjuntos de nós com etiquetas, recomendamos a utilização de uma política de admissão de validação. Esta política, uma funcionalidade integrada do Kubernetes, interceta pedidos para criar ou atualizar Pods antes de serem persistidos. Esta interceção impede a execução de cargas de trabalho não autorizadas em nós etiquetados.

A seguinte política nega pedidos de criação de agrupamentos se o agrupamento contiver uma tolerância para uma das contaminações da classe de computação listadas e não estiver num espaço de nomes permitido.

1. Guarde o seguinte manifesto como restrict-toleration.yaml:

   # Copyright 2025 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #      http://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   apiVersion: admissionregistration.k8s.io/v1
   kind: ValidatingAdmissionPolicy
   metadata:
     name: restrict-toleration
   spec:
     failurePolicy: Fail
     paramKind:
       apiVersion: v1
       kind: ConfigMap
     matchConstraints:
       # GKE will mutate any pod specifying a CC label in a nodeSelector
       # or in a nodeAffinity with a toleration for the CC node label.
       # Mutation hooks will always mutate the K8s object before validating
       # the admission request.  
       # Pods created by Jobs, CronJobs, Deployments, etc. will also be validated.
       # See https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#admission-control-phases for details
       resourceRules:
       - apiGroups:   [""]
         apiVersions: ["v1"]
         operations:  ["CREATE", "UPDATE"]
         resources:   ["pods"]
     matchConditions:
       - name: 'match-tolerations'
         # Validate only if compute class toleration exists
         # and the CC label tolerated is listed in the configmap.
         expression: > 
           object.spec.tolerations.exists(t, has(t.key) &&
           t.key == 'cloud.google.com/compute-class' &&
           params.data.computeClasses.split('\\n').exists(cc, cc == t.value))
     validations:
       # ConfigMap with permitted namespace list referenced via `params`.
       - expression: "params.data.namespaces.split('\\n').exists(ns, ns == object.metadata.namespace)"
         messageExpression: "'Compute class toleration not permitted on workloads in namespace ' + object.metadata.namespace"
   
   ---
   apiVersion: admissionregistration.k8s.io/v1
   kind: ValidatingAdmissionPolicyBinding
   metadata:
     name: restrict-toleration-binding
   spec:
     policyName: restrict-toleration
     validationActions: ["Deny"]
     paramRef:
       name: allowed-ccc-namespaces
       namespace: default
       parameterNotFoundAction: Deny
   ---
   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: allowed-ccc-namespaces
     namespace: default
   data:
     # Replace example namespaces in line-separated list below.
     namespaces: |
       foo
       bar
       baz
     # ComputeClass names to monitor with this validation policy.
     # The 'autopilot' and 'autopilot-spot' CCs are present on
     # all NAP Standard and Autopilot clusters.
     computeClasses: |
       MY_COMPUTE_CLASS
       autopilot
       autopilot-spot
   
   

2. Aplique o manifesto:

   kubectl apply -f restrict-toleration.yaml
   

Ajustar as políticas de admissão de validação para satisfazer as necessidades de segurança específicas da sua organização.

Valide as etiquetas de firewall no cluster

• Liste as etiquetas nos clusters do Autopilot:

  gcloud container clusters describe CLUSTER_NAME \
      --location=LOCATION \
      --format="value(nodePoolAutoConfig.resourceManagerTags)"
  

  Substitua o seguinte:

  • CLUSTER_NAME: o nome do cluster.
  • LOCATION: a região ou a zona do Compute Engine do cluster.

• Liste as etiquetas em node pools específicos:

  Este comando também valida as etiquetas em pools de nós aprovisionados automaticamente por uma classe de computação personalizada.

  gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format="value(config.resourceManagerTags)"
  

  Substitua o seguinte:

  • NODE_POOL_NAME: o nome do node pool.
  • CLUSTER_NAME: o nome do cluster.
  • LOCATION: a região ou a zona do Compute Engine do cluster.

Desassocie etiquetas de firewall de clusters e node pools

Para remover etiquetas de firewall de clusters e conjuntos de nós, atualize o recurso com um valor vazio para as etiquetas.

Desassocie etiquetas de clusters do Autopilot

Execute o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --autoprovisioning-resource-manager-tags=

Desassocie etiquetas de conjuntos de nós

1. Desassocie etiquetas de nós ao nível do cluster: autoprovisioning

   gcloud container clusters update CLUSTER_NAME \
       --location=LOCATION \
       --autoprovisioning-resource-manager-tags=
   

   O GKE não anexa etiquetas a novos conjuntos de nós aprovisionados automaticamente.

2. Desanexe etiquetas de node pool:

   gcloud container node-pools update NODE_POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=LOCATION \
       --resource-manager-tags=
   

   O GKE remove as etiquetas existentes desse conjunto de nós.

Elimine chaves e valores de etiquetas

Para eliminar uma chave ou um valor de etiqueta, certifique-se de que a etiqueta está desanexada de todos os recursos. Em seguida, consulte o artigo Eliminar etiquetas na documentação do Resource Manager.

Compare as etiquetas de rede com as etiquetas

A utilização de etiquetas para a aplicação de políticas de firewall tem vantagens significativas em termos de segurança e usabilidade em comparação com as etiquetas de rede. Da mesma forma, as políticas de firewall de rede melhoram as capacidades das regras de firewall de VPC, facilitando a aplicação de regras de firewall em organizações, pastas, projetos ou redes inteiras.

A utilização de etiquetas com políticas de firewall de rede é uma forma mais segura e escalável de gerir o acesso aos seus ambientes do GKE na sua organização. Pode usar etiquetas de rede no mesmo cluster que as etiquetas, embora não possa usar etiquetas de rede para aplicar políticas de firewall de rede.

Para uma comparação detalhada entre etiquetas e etiquetas de rede, consulte o artigo Comparação entre etiquetas e etiquetas de rede na documentação do Cloud NGFW.

Diferenças funcionais nos conjuntos de nós aprovisionados automaticamente

Nos clusters do Autopilot e nos node pools padrão que não usam o aprovisionamento automático de nós, as etiquetas de rede e as etiquetas apresentam um comportamento semelhante. A tabela seguinte mostra as diferenças funcionais entre as etiquetas de rede e as etiquetas em conjuntos de nós aprovisionados automaticamente em clusters padrão:

O que se segue?

• Use etiquetas para o acompanhamento da utilização e a aplicação de políticas de IAM
• Saiba mais sobre as etiquetas para firewalls
• Saiba mais sobre as etiquetas