Applicare in modo selettivo i criteri firewall in GKE

Questa pagina mostra come applicare in modo selettivo i criteri firewall di rete di Cloud Next Generation Firewall in Google Kubernetes Engine (GKE) utilizzando i tag. I tag offrono un controllo più granulare per organizzare la gerarchia delle risorse rispetto alla Google Cloud gerarchia delle risorse predefinita. I tag consentono anche l'applicazione condizionale dei criteri.

Questa pagina è dedicata agli esperti di sicurezza che vogliono un controllo granulare sulle policy firewall in GKE. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta la pagina Ruoli utente e attività comuni di GKE. Google Cloud

Prima di leggere questa pagina, assicurati di avere familiarità con i seguenti concetti:

Informazioni sui tag

I tag sono coppie chiave-valore che ti consentono di annotare e gestire le tue risorseGoogle Cloud a livello di organizzazione o progetto. Puoi utilizzare i tag per organizzare le risorse e applicare in modo condizionale criteri come firewall o criteri IAM. Puoi utilizzare controllo dell'accessoo IAM per definire chi può collegare, creare, aggiornare o eliminare i tag.

Per saperne di più sui tag, consulta la panoramica dei tag nella documentazione di Resource Manager.

Utilizzare i tag per applicare le policy firewall di rete

Puoi utilizzare i tag per applicare in modo condizionale i criteri firewall di rete globali o regionali ai nodi GKE. Devi designare lo scopo GCE_FIREWALL per i tag che vuoi utilizzare con i criteri firewall di rete. Quando applichi i tag di scopo del firewall ai cluster o ai pool di nodi GKE, GKE li associa automaticamente alle macchine virtuali (VM) Compute Engine corrispondenti.

I tag per i criteri firewall di rete sostituiscono la necessità di utilizzare i tag di rete, ovvero metadati che chiunque può collegare alle VM Compute Engine sottostanti per l'applicazione delle regole firewall di Virtual Private Cloud e che non supportano il controllo dell'accesso dell'accesso IAM. Se utilizzi i tag di rete con le regole firewall VPC, ti consigliamo di eseguire la migrazione ai criteri firewall di rete e di utilizzare tag firewall sicuri. Per un confronto dettagliato, vedi Confrontare i tag di rete con i tag in questo documento.

Tag per il flusso di lavoro delle policy del firewall di rete

Per utilizzare i tag con i criteri firewall di rete in GKE, svolgi le seguenti operazioni:

  1. Creare un tag:

    1. Definisci una chiave tag a livello di organizzazione o progetto, ad esempio env.
    2. Definisci i valori dei tag possibili per la chiave, ad esempio dev, staging e prod.

    3. Specifica il tag per l'utilizzo della policy firewall di rete.

  2. Concedi agli utenti l'accesso per interagire con il tag firewall.

  3. Applica coppie chiave-valore di tag a cluster GKE, pool di nodi specifici o utilizzali in ComputeClass personalizzate per applicarli ai nodi per carichi di lavoro specifici. GKE associa automaticamente i tag alle VM Compute Engine sottostanti per l'applicazione delle policy firewall.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

  • Attiva l'API Google Kubernetes Engine.
    • Attiva l'API Google Kubernetes Engine
  • Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

Requisiti e limitazioni

  • I tag per i criteri firewall di rete sono supportati in GKE 1.28 e versioni successive. Se utilizzi una versione di GKE precedente alla 1.28, utilizza i tag di rete con le regole firewall VPC.
  • I cluster e i pool di nodi GKE non supportano i tag creati con il flag --purpose-data=organization=auto. Per i carichi di lavoro GKE, ti consigliamo di creare tag con ambito limitato alla tua rete VPC utilizzando il flag --purpose-data=network. Per saperne di più, consulta Creare tag.
  • Il cluster GKE e il tag devono essere associati alla stessa rete VPC.
  • Nei cluster Standard, ogni pool di nodi supporta fino a cinque tag firewall collegati.
  • I cluster Autopilot supportano fino a cinque tag firewall.
  • Custom Compute Class supporta fino a cinque tag.
  • GKE rifiuta le chiavi tag che utilizzano il prefisso gke-managed.
  • Devi creare le coppie chiave-valore dei tag prima di poterle collegare a cluster o pool di nodi.

Ruoli e autorizzazioni IAM

Per ottenere le autorizzazioni necessarie per utilizzare i tag per le policy firewall in GKE, chiedi all'amministratore di concederti i seguenti ruoli IAM:

  • Per concedere le autorizzazioni richieste per i tag agli utenti e agli agenti di servizio GKE:
  • Per creare e amministrare i tag: Tag Administrator (roles/resourcemanager.tagAdmin) sull'organizzazione o sul progetto
  • Per collegare i tag alle risorse: Tag User (roles/resourcemanager.tagUser) sul progetto

Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

Creare tag

Per poterli allegare a cluster o nodi, i tag devono esistere. Per creare un tag, consulta Utilizzare i tag per i firewall nella documentazione di Cloud NGFW.

Ad esempio, per creare un tag firewall con ambito di progetto, esegui questi comandi:

  1. Crea la chiave tag:

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

    Sostituisci quanto segue:

    • TAG_KEY: il nome della chiave del tag, ad esempio env
    • PROJECT_ID: il tuo Google Cloud ID progetto
    • NETWORK_NAME: il nome della rete VPC che utilizzerai con il tag

  2. Recupera l'ID della chiave del tag:

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

    L'output è tagKeys/KEY_ID, dove KEY_ID è un ID numerico per la chiave. Prendi nota di questo ID per utilizzarlo in seguito.

  3. Aggiungi un valore tag alla chiave tag:

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

    Sostituisci TAG_VALUE con il nome di un valore consentito per quella chiave tag, ad esempio dev.

Utilizza la sintassi corretta dei tag nei comandi gcloud CLI

Quando fai riferimento ai tag utilizzando gcloud CLI, devi formattare le coppie chiave-valore utilizzando una delle seguenti sintassi:

Sintassi dei tag 
tagKeys/KEY_ID=tagValues/VALUE_ID

Sostituisci quanto segue:

  • KEY_ID: l'ID numerico della chiave
  • VALUE_ID: l'ID del valore numerico

Ad esempio, tagKeys/123456789=tagValues/987654321.

 
ORGANIZATION_ID/TAG_KEY=TAG_VALUE

Sostituisci quanto segue:

  • ORGANIZATION_ID: l'ID organizzazione Google Cloud numerico
  • TAG_KEY: il nome della chiave del tag che hai creato
  • TAG_VALUE: il nome del valore tag che hai creato

Ad esempio, 12345678901/env=dev.

 
PROJECT_ID/TAG_KEY=TAG_VALUE

Sostituisci quanto segue:

  • PROJECT_ID: il tuo Google Cloud ID progetto
  • TAG_KEY: il nome della chiave del tag che hai creato
  • TAG_VALUE: il nome del valore tag che hai creato

Ad esempio, example-project/env=dev.

 
PROJECT_NUMBER/TAG_KEY=TAG_VALUE

Sostituisci quanto segue:

  • PROJECT_ID: l'identificatore numerico del tuo progetto Google Cloud
  • TAG_KEY: il nome della chiave del tag che hai creato
  • TAG_VALUE: il nome del valore tag che hai creato

Ad esempio, 11223344556/env=dev.

Tag di destinazione con criteri firewall

Dopo aver creato i tag, puoi fare riferimento a coppie chiave-valore specifiche nelle regole dei criteri firewall. Per istruzioni, vedi Utilizzare i tag per i firewall.

Concedi autorizzazioni IAM agli agenti di servizio

Affinché GKE possa collegare automaticamente i tag ai nuovi nodi durante gli eventi di scalabilità verticale, devi concedere i ruoli IAM corrispondenti ai service account gestiti da Google Cloud, chiamati anche agenti di servizio.

  1. Concedi il ruolo Utente tag (roles/resourcemanager.tagUser) all'agente di servizio Kubernetes Engine:

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

    Sostituisci PROJECT_NUMBER con il numero di progetto Google Clouddel cluster. Per trovare il numero di progetto, esegui questo comando:

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

  2. Concedi il ruolo Amministratore blocchi tag (roles/resourcemanager.tagHoldAdmin) all'agente di servizio di Kubernetes Engine per la coppia chiave-valore del tag:

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

    Questo ruolo consente all'agente di servizio di impedire l'eliminazione del tag se la coppia chiave-valore è ancora in uso in GKE.

  3. Concedi il ruolo Utente tag (roles/resourcemanager.tagUser) all'agente di servizio API di Google:

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

Concedere ruoli IAM aggiuntivi per i tag al di fuori del progetto

Per utilizzare tag di proprietà di un'organizzazione o di un progetto diverso da quello del cluster, segui questi passaggi aggiuntivi:

  1. Concedi al service agent Kubernetes Engine l'accesso al ruolo Utente tag (roles/resourcemanager.tagUser) per i tag nella risorsa padre:

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

    Sostituisci quanto segue:

    • PARENT_RESOURCE: l'ID progetto o l'ID organizzazione della risorsa proprietaria del tag
    • PROJECT_NUMBER: il numero di progetto del progetto cluster

  2. Concedi l'accesso al service agent delle API di Google per i tag nella risorsa padre con il ruolo Utente tag (roles/resourcemanager.tagUser):

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

  3. Concedi il ruolo Amministratore dei tag (roles/resourcemanager.tagHoldAdmin) all'agente di servizio Kubernetes Engine per la coppia chiave-valore del tag:

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

Collega i tag firewall ai cluster Autopilot

I tag firewall vengono collegati ai cluster Autopilot a livello di cluster. GKE applica automaticamente questi tag a livello di cluster a ogni nodo.

Allegare tag quando crei un nuovo cluster Autopilot

Esegui questo comando:

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

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del nuovo cluster.
  • LOCATION: la regione Compute Engine del cluster.
  • TAG1,TAG2,...: un insieme separato da virgole di coppie chiave-valore da allegare. Ogni coppia chiave-valore deve utilizzare una sintassi supportata, come descritto nella sezione Sintassi dei tag nei comandi. Ad esempio, example-project/env=dev,1234567901/team=sre.

Allegare tag ai cluster Autopilot esistenti

Esegui questo comando:

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

Quando aggiorni i tag di un cluster, GKE sovrascrive tutti i tag esistenti su tutti i nodi.

Collega tag firewall a cluster Standard e pool di nodi

Il metodo che utilizzi per collegare i tag dipende dal fatto che vuoi che gli altri pool di nodi nel cluster ereditino i tag, come segue:

Tag firewall standard del cluster
--autoprovisioning-resource-manager-tags

Impostazione a livello di cluster

GKE applica i tag a tutti i node pool di cui è stato eseguito il provisioning automatico nuovi nel cluster.

Se utilizzi questo flag in un cluster esistente, GKE non applica i tag ai pool di nodi esistenti nel cluster. I pool di nodi esistenti conservano i tag già applicati prima dell'aggiornamento. Per aggiornare i tag dei node pool esistenti, utilizza il flag --resource-manager-tags.
--resource-manager-tags

Impostazione a livello di node pool

GKE applica i tag al pool di nodi specificato. Se utilizzi questo flag durante la creazione del cluster, GKE applica i tag al pool di nodi predefinito che crea. Se utilizzi questo flag su un pool di nodi con provisioning automatico, GKE sovrascrive tutti i tag esistenti nel pool di nodi.

Allegare tag firewall ai cluster Standard

Puoi allegare tag a cluster standard nuovi o esistenti. Quando colleghi i tag a un intero cluster, GKE considera questi tag impostati a livello di cluster.

Allegare tag a un nuovo cluster Standard con il provisioning automatico dei nodi

GKE utilizza i tag a livello di cluster per i nuovi nodi di cui è stato eseguito il provisioning automatico per impostazione predefinita. Il pool di nodi predefinito creato da GKE nel cluster non viene sottoposto a provisioning automatico e non riceve questi tag.

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

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del nuovo cluster
  • LOCATION: la regione o la zona di Compute Engine per il cluster
  • TAG1,TAG2,...: un insieme separato da virgole di coppie chiave-valore da allegare. Ogni coppia chiave-valore deve utilizzare una sintassi supportata, come descritto nella sezione Sintassi dei tag nei comandi. Ad esempio, example-project/env=dev,1234567901/team=sre.
  • MAX_CPU: il numero massimo di core per il cluster
  • MAX_MEMORY: la capacità massima di memoria per il cluster in gigabyte

Allegare tag quando abiliti il provisioning automatico dei nodi su un cluster esistente

GKE applica questi tag solo ai nuovi node pool di cui è stato eseguito il provisioning automatico. I pool di nodi esistenti conservano i tag che avevano prima dell'aggiornamento.

  1. Associa tag al cluster:

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

  2. Abilita il provisioning automatico dei nodi sul cluster:

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

Associa tag firewall ai node pool

Puoi collegare tag a node pool nuovi o esistenti, indipendentemente dal fatto che utilizzino il provisioning automatico dei nodi. GKE considera questi tag come un'impostazione a livello di node pool.

Collega i tag al pool di nodi predefinito

GKE associa i tag specificati utilizzando il flag --resource-manager-tags quando crei un cluster al pool di nodi predefinito creato da GKE nel cluster.

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

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del nuovo cluster
  • LOCATION: la regione o la zona di Compute Engine per il cluster
  • TAG1,TAG2,...: un insieme separato da virgole di coppie chiave-valore da allegare. Ogni coppia chiave-valore deve utilizzare una sintassi supportata, come descritto nella sezione Sintassi dei tag nei comandi. Ad esempio, example-project/env=dev,1234567901/team=sre.

Collega tag a un nuovo pool di nodi

Quando utilizzi il flag --resource-manager-tags durante la creazione pool di nodi, GKE collega i tag specificati al pool di nodi.

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

Sostituisci quanto segue:

  • NODE_POOL_NAME: il nome del nuovo pool di nodi
  • CLUSTER_NAME: il nome del cluster
  • LOCATION: la regione o la zona Compute Engine del cluster
  • TAG1,TAG2,...:un insieme separato da virgole di coppie chiave-valore da allegare. Ogni coppia chiave-valore deve utilizzare una sintassi supportata, come descritto nella sezione Sintassi dei tag nei comandi. Ad esempio, example-project/env=dev,1234567901/team=sre.

Allegare tag a un pool di nodi esistente

Quando aggiorni i tag di un pool di nodi esistente utilizzando il flag --resource-manager-tags, GKE sovrascrive tutti i tag esistenti nel pool di nodi. Puoi utilizzare questo comando per aggiornare i tag sui node pool di cui è stato eseguito il provisioning automatico.

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

Sostituisci NODE_POOL_NAME con il nome del pool di nodi da aggiornare.

Attivare/disattivare le impostazioni di provisioning automatico nei cluster e nei pool di nodi esistenti

Quando aggiorni i tag a livello di cluster, GKE applica questi nuovi tag a tutti i nuovi node pool nel cluster e conserva i tag associati ai node pool esistenti.

Quando aggiorni i pool di nodi esistenti per abilitare o disabilitare il provisioning automatico dei nodi, considera le seguenti implicazioni per i tag:

  • Quando abiliti o disabiliti il provisioning automatico dei nodi, il pool di nodi conserva i tag esistenti. GKE non sovrascrive questi tag con tag a livello di cluster, nemmeno durante la ricreazione dei nodi.
  • Se aggiorni manualmente i tag su node pool specifici, GKE sovrascrive i tag esistenti con i tag specificati per quelpool di nodil.

Applica tag ai carichi di lavoro con ComputeClass personalizzate

Puoi applicare i tag firewall a node pool specifici nei cluster Autopilot e nei cluster Standard che utilizzano il provisioning automatico dei nodi (NAP) utilizzando ComputeClass personalizzate (CCC). Una classe di calcolo personalizzata è una risorsa che ti consente di definire una configurazione per un gruppo di nodi, inclusa la definizione dei tag Resource Manager da applicare ai nodi.

Quando esegui il deployment di un workload che richiede un nodo con un'etichetta Custom Compute Class specifica, NAP verifica innanzitutto se esiste già un pool di nodi che soddisfa tutti i requisiti di Custom Compute Class, inclusi i tag Resource Manager specificati.

Se non esiste pool di nodi corrispondente, NAP crea un nuovo pool di nodi per il carico di lavoro con la configurazione specificata e associa i tag alle VM Compute Engine sottostanti. Questa creazione automatica del pool di nodi garantisce che i carichi di lavoro vengano eseguiti su nodi con i tag firewall corretti per l'applicazione dei criteri.

Creare una ComputeClass personalizzata utilizzando i tag

  1. Per creare un ComputeClass con i tag, salva il seguente manifest come my-compute-class.yaml. Nel campo resourceManagerTags, specifica le chiavi e i valori dei tag da associare ai node pool creati utilizzando questa 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"

    Sostituisci quanto segue:

    • COMPUTE_CLASS_NAME: il nome della classe di calcolo personalizzata, ad esempio my-custom-class.
    • PROJECT_ID: il tuo ID progetto Google Cloud .
    • TAG_KEY_1: il nome della prima chiave tag.
    • TAG_VALUE_1: il nome del primo valore tag.
    • ORGANIZATION_ID: l'ID organizzazione Google Cloud numerico.
    • TAG_KEY_2: il nome della seconda chiave tag.
    • TAG_VALUE_2: il nome del secondo valore tag.
    • KEY_ID: l'ID numerico di una chiave tag.
    • VALUE_ID: l'ID numerico di un valore tag.

  2. Applica il manifest:

    kubectl apply -f my-compute-class.yaml

Se specifichi un tag non valido o se gli agenti di servizio GKE non dispongono delle autorizzazioni IAM richieste per il tag, GKE non esegue il provisioning di un pool di nodi per il tuo carico di lavoro e il carico di lavoro rimane nello stato Pending. Per saperne di più sull'errore, consulta il campo Status della risorsa ComputeClass.

Per controllare lo stato, esegui questo comando:

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

Sostituisci COMPUTE_CLASS_NAME con il nome della tua classe di calcolo personalizzata.

Targeting della classe di calcolo personalizzata nel carico di lavoro

  1. Per scegliere come target la ComputeClass che hai creato, salva il seguente manifest come pod-with-ccc.yaml. Questo manifest utilizza il campo nodeSelector per scegliere come target la classe di calcolo.

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

    Sostituisci COMPUTE_CLASS_NAME con il nome della tua classe di calcolo personalizzata, ad esempio my-custom-class.

  2. Applica il manifest:

    kubectl apply -f pod-with-ccc.yaml

Quando pianifichi un workload che ha come target una classe di calcolo personalizzata, GKE applica automaticamente un taint ai nodi creati per quella classe e aggiunge una tolleranza corrispondente ai pod del workload in modo che solo i pod che richiedono esplicitamente la classe vengano pianificati su questi nodi.

Autorizzare i workload con un criterio di ammissione di convalida (VAP)

Per contribuire a garantire che solo i carichi di lavoro autorizzati possano essere pianificati sui pool di nodi con tag, ti consigliamo di utilizzare un Validating Admission Policy. Questa policy, una funzionalità integrata di Kubernetes, intercetta le richieste di creazione o aggiornamento dei pod prima che vengano resi persistenti. Questa intercettazione impedisce l'esecuzione di carichi di lavoro non autorizzati sui nodi taggati.

Il seguente criterio nega le richieste di creazione di pod se il pod contiene una tolleranza per uno dei taint di Compute Class elencati e non si trova in uno spazio dei nomi consentito.

  1. Salva il seguente manifest come 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. Applica il manifest:

    kubectl apply -f restrict-toleration.yaml

Modifica i criteri di ammissione di convalida per soddisfare le esigenze di sicurezza specifiche della tua organizzazione.

Verifica i tag firewall sul cluster

  • Elenca i tag sui cluster Autopilot:

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

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster.
    • LOCATION: la regione o la zona Compute Engine del cluster.

  • Elenca i tag su node pool specifici:

    Questo comando verifica anche i tag sui pool di nodi di cui è stato eseguito il provisioning automatico da una classe di computing personalizzata.

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

    Sostituisci quanto segue:

    • NODE_POOL_NAME: il nome del pool di nodi.
    • CLUSTER_NAME: il nome del cluster.
    • LOCATION: la regione o la zona Compute Engine del cluster.

Scollega i tag firewall da cluster e pool di nodi

Per rimuovere i tag firewall dai cluster e dai pool di nodi, aggiorna la risorsa con un valore vuoto per i tag.

Scollega i tag dai cluster Autopilot

Esegui questo comando:

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

Scollega i tag dai node pool

  1. Scollega i tag del nodo autoprovisioning a livello di cluster:

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

    GKE non associa tag ai nuovi node pool di cui è stato eseguito il provisioning automatico.

  2. Scollega i tag del pool di nodi:

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

    GKE rimuove i tag esistenti da questo pool di nodi.

Eliminare chiavi e valori dei tag

Per eliminare una chiave o un valore tag, assicurati che il tag sia scollegato da tutte le risorse. Poi, consulta Eliminazione dei tag nella documentazione di Resource Manager.

Confrontare i tag di rete con i tag

L'utilizzo dei tag per l'applicazione dei criteri firewall offre vantaggi significativi in termini di sicurezza e usabilità rispetto ai tag di rete. Analogamente, i criteri firewall di rete migliorano le funzionalità delle regole firewall VPC facilitando l'applicazione delle regole firewall in intere organizzazioni, cartelle, progetti o reti.

L'utilizzo dei tag con i criteri firewall di rete è un modo più sicuro e scalabile per gestire l'accesso agli ambienti GKE in tutta l'organizzazione. Puoi utilizzare i tag di rete nello stesso cluster dei tag, anche se non puoi utilizzarli per applicare i criteri firewall di rete.

Per un confronto dettagliato tra tag e tag di rete, vedi Confronto tra tag e tag di rete nella documentazione di Cloud NGFW.

Differenze funzionali nei node pool di cui è stato eseguito il provisioning automatico

Nei cluster Autopilot e nei node pool Standard che non utilizzano il provisioning automatico dei nodi, i tag di rete e i tag mostrano un comportamento simile. La seguente tabella mostra le differenze funzionali tra i tag di rete e i tag nei node pool di cui è stato eseguito il provisioning automatico nei cluster Standard:

Azione Comportamento dei tag di rete Comportamento dei tag
GKE esegue il provisioning automatico di un pool di nodi GKE applica i tag di rete a livello di cluster GKE applica i tag a livello di cluster
Aggiorni i tag o i tag di rete in un pool di nodi di cui è stato eseguito il provisioning automatico
  • Se esistono tag di rete a livello di cluster, l'operazione di aggiornamento non riesce
  • Se i tag di rete a livello di cluster non esistono, GKE sovrascrive i tag di rete esistenti per il pool di nodi
 GKE sovrascrive i tag esistenti per il pool di nodi indipendentemente dall'esistenza di tag a livello di cluster
Aggiorni i tag o i tag di rete per l'intero cluster GKE sovrascrive i tag di rete per i pool di nodi con provisioning automatico nuovi ed esistenti nel cluster. GKE applica i nuovi tag a livello di cluster ai nuovi node pool di cui è stato eseguito il provisioning automatico. I pool di nodi di cui è stato eseguito il provisioning automatico mantengono i tag che avevano prima dell'aggiornamento.

Passaggi successivi