Protezione dei metadati del cluster

Standard

---

Google Kubernetes Engine (GKE) utilizza i metadati delle istanze per configurare le macchine virtuali (VM), ma alcuni di questi metadati sono potenzialmente sensibili e dovrebbero essere protetti dai carichi di lavoro in esecuzione sul cluster.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

• Abilita l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti dell'interfaccia a riga di comando gcloud, assicurati di impostare le proprietà compute/region e compute/zone. Impostando le località predefinite, puoi evitare errori nellgcloud CLI come segue: One of [--zone, --region] must be supplied: Please specify location.

Configura l'account di servizio del nodo

Le credenziali dell'account di servizio di ogni nodo continuano a essere esposte ai carichi di lavoro. Per impostazione predefinita, i nodi utilizzano l'account di servizio predefinito di Compute Engine. Devi configurare un account di servizio con privilegi minimi per i nodi da utilizzare al posto dell'account di servizio predefinito di Compute Engine. Quindi, collega questo account di servizio ai nodi in modo che un utente malintenzionato non possa aggirare le protezioni dei metadati di GKE utilizzando l'API Compute Engine per accedere direttamente alle istanze VM sottostanti.

Per saperne di più, consulta Utilizzare gli account di servizio dei nodi con privilegio minimo minimi.

Attenzione: non utilizzare un account di servizio con l'autorizzazione compute.instances.get, il ruolo Amministratore istanze Compute o altre autorizzazioni simili, in quanto consentono a potenziali utenti malintenzionati di ottenere i metadati delle istanze utilizzando l'API Compute Engine. Limita le autorizzazioni di una VM nodo utilizzando le autorizzazioni dell'account di servizio, non gli ambiti di accesso. Per saperne di più, consulta Migrazione da ambiti di accesso legacy.

Per creare un account di servizio dei nodi con privilegi minimi, esegui questi passaggi:

1. Crea un nuovo account di servizio Identity and Access Management (IAM) e salva l'indirizzo email in una variabile di ambiente:

   gcloud iam service-accounts create NODE_SA_NAME \
       --display-name="DISPLAY_NAME"
   export NODE_SA_EMAIL=$(gcloud iam service-accounts list --format='value(email)' \
       --filter='displayName:DISPLAY_NAME')
   

   Sostituisci quanto segue:

   • NODE_SA_NAME: il nome del nuovo account di servizio del nodo.
   • DISPLAY_NAME: il nome visualizzato del nuovo account di servizio.

   L'indirizzo email dell'account di servizio del nodo ha il formato NODE_SA_NAME@PROJECT_ID.iam.gserviceaccount.com.

2. Configura il tuo account di servizio con i ruoli e le autorizzazioni minimi per eseguire i nodi GKE:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:$NODE_SA_EMAIL \
       --role=roles/monitoring.metricWriter
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:$NODE_SA_EMAIL \
       --role=roles/monitoring.viewer
   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:$NODE_SA_EMAIL \
       --role=roles/logging.logWriter
   

   Sostituisci PROJECT_ID con l'ID del tuo progetto Google Cloud.

   Inoltre, se il cluster estrae immagini private da Artifact Registry, aggiungi il ruolo roles/artifactregistry.reader:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:$NODE_SA_EMAIL \
       --role=roles/artifactregistry.reader
   

Occultamento dei metadati

Avviso: la federazione delle identità per i carichi di lavoro per GKE sostituisce la necessità di utilizzare l'occultamento dei metadati e i due approcci sono incompatibili. Ti consigliamo di utilizzare la federazione delle identità per i carichi di lavoro per GKE, anziché l'occultamento dei metadati. L'occultamento dei metadati è pianificato per essere deprecato e rimosso in futuro.

Beta

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

L'occultamento dei metadati di GKE protegge alcuni metadati di sistema potenzialmente sensibili dai carichi di lavoro degli utenti in esecuzione sul cluster.

Puoi abilitare l'occultamento dei metadati per impedire ai pod utente di accedere a determinati metadati della VM nei nodi del cluster, ad esempio le credenziali kubelet e le informazioni sulle istanze VM. In particolare, l'occultamento dei metadati protegge l'accesso a kube-env (che contiene le credenziali Kubelet) e al token di identità dell'istanza della VM.

I metadati nascondono il traffico dei firewall dai pod utente (pod non in esecuzione su HostNetwork) al server dei metadati del cluster, consentendo solo query sicure. Il firewall impedisce ai pod utente di utilizzare le credenziali kubelet per attacchi di escalation dei privilegi o di utilizzare l'identità delle VM per attacchi di escalation delle istanze.

Puoi abilitare l'occultamento dei metadati solo quando crei un nuovo cluster o quando aggiungi un nuovo pool di nodi a un cluster esistente.

Limitazioni

• L'occultamento dei metadati protegge solo l'accesso a kube-env e al token di identità dell'istanza del nodo.
• L'occultamento dei metadati non limita l'accesso all'account di servizio del nodo.
• L'occultamento dei metadati non limita l'accesso ad altri metadati dell'istanza correlati.
• L'occultamento dei metadati non limita l'accesso ad altre API di metadati legacy.
• L'occultamento dei metadati non limita il traffico dai pod in esecuzione sulla rete host (hostNetwork: true nella specifica del pod).

Creazione di un nuovo cluster o pool di nodi con occultamento dei metadati

Dopo aver creato un account di servizio, puoi creare un nuovo cluster o pool di nodi con l'occultamento dei metadati abilitato utilizzando Google Cloud CLI.

Crea un nuovo cluster

Per creare un cluster con l'occultamento dei metadati abilitato, esegui questo comando:

gcloud beta container clusters create CLUSTER_NAME \
  --workload-metadata-from-node=SECURE \
  --service-account=$NODE_SA_EMAIL

Sostituisci CLUSTER_NAME con il nome del nuovo cluster.

Il flag --workload-metadata-from-node accetta i seguenti valori:

• SECURE: attiva l'occultamento dei metadati.
• EXPOSED o UNSPECIFIED: disattiva l'occultamento dei metadati.

Crea un nuovo pool di nodi

Per creare un pool di nodi con l'occultamento dei metadati abilitato, esegui questo comando:

gcloud beta container node-pools create NODE_POOL_NAME \
  --cluster=CLUSTER_NAME \
  --workload-metadata-from-node=SECURE \
  --service-account=$NODE_SA_EMAIL

Sostituisci NODE_POOL_NAME con il nome del nuovo pool di nodi.

Verifica dei metadati del token di identità nascosti dal carico di lavoro del cluster

Quando nascondi i metadati, non dovrebbe essere possibile richiedere una firma tramite il token di identità dell'istanza del nodo. Per verificare che le richieste informino esplicitamente gli utenti dei metadati nascosti:

1. Apri una sessione di shell in un nuovo pod:

   kubectl run metadata-concealment -it --image=google/cloud-sdk:slim -- /bin/bash
   

2. Nel pod, prova a ottenere un endpoint nascosto:

   curl -H "Metadata-Flavor: Google" \
   'http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=https://www.example.com'
   

   L'output è simile al seguente:

   This metadata endpoint is concealed.
   

Disabilitazione e transizione dalle API dei metadati legacy

Gli endpoint del server di metadati v0.1 e v1beta1 di Compute Engine sono stati deprecati e verranno disattivati il 30 settembre 2020.

Per la pianificazione dell'arresto, consulta l'articolo Ritiro degli endpoint dei server di metadati v0.1 e v1beta1.

Passaggi successivi

• Abilita la federazione di Workload Identity per GKE sui tuoi cluster.