Informazioni sull'isolamento di rete in GKE

Puoi personalizzare l'accesso alla rete per il control plane e i nodi del tuo cluster Google Kubernetes Engine (GKE) per migliorare la sicurezza di rete del cluster e dei relativi carichi di lavoro. Questo documento spiega i vari tipi di isolamento che puoi configurare per il tuo cluster, i vantaggi dell'isolamento della rete e le limitazioni da considerare prima di isolare il cluster.

Per configurare livelli di isolamento specifici per il tuo cluster, consulta i seguenti documenti:

Best practice:

Pianifica e progetta la configurazione dell'isolamento di rete con gli architetti di rete, gli ingegneri di rete, gli amministratori di rete o un altro team della tua organizzazione responsabile della definizione, dell'implementazione e della manutenzione dell'architettura di rete.

Tipi di accesso alla rete

I componenti del cluster, come il control plane, il server API e i nodi, inviano e ricevono traffico di rete per scopi diversi. Puoi personalizzare l'isolamento del cluster controllando uno o più dei seguenti tipi di accesso alla rete:

  • Accesso al control plane da fonti esterne: personalizza chi può accedere al control plane per eseguire attività come l'esecuzione di comandi kubectl nel cluster.
  • Accesso a webhook esterni dal server API: personalizza se il server API Kubernetes può inviare traffico direttamente ai server webhook esterni tramite il control plane.
  • Accesso ai nodi da fonti esterne:personalizza se i client esterni sulla rete internet pubblica possono accedere ai tuoi nodi.

Accesso al control plane da origini esterne

In questa sezione, valuterai chi può accedere al control plane.

Ogni cluster GKE ha un control plane che gestisce le richieste dell'API Kubernetes. Il control plane viene eseguito su una macchina virtuale (VM) che si trova in una rete VPC in un progetto gestito da Google. Un cluster regionale ha più repliche del control plane, ognuna delle quali viene eseguita sulla propria VM. I principal come gli amministratori del cluster utilizzano un endpoint del control plane per accedere al cluster per attività come l'esecuzione di comandi kubectl o il deployment di workload. L'endpoint del control plane viene utilizzato dai client esterni per accedere al cluster e non viene utilizzato per la comunicazione diretta con le istanze VM di Compute Engine che ospitano le repliche del control plane. Il control plane ha i seguenti tipi di endpoint per l'accesso al cluster:

Il control plane ha due tipi di endpoint per l'accesso al cluster:

  • Endpoint basato su DNS
  • Endpoint basati su IP
Best practice:

Utilizza solo l'endpoint basato su DNS per accedere al control plane per una configurazione semplificata e un livello di sicurezza flessibile e basato su policy.

Endpoint basato su DNS

L'endpoint basato su DNS fornisce un DNS o un nome di dominio completo (FQDN) univoco e immutabile per ogni control plane del cluster. Questo nome DNS può essere utilizzato per accedere al control plane per l'intero ciclo di vita. Il nome DNS viene risolto in un endpoint accessibile da qualsiasi rete raggiungibile dalle API Google Cloud , incluse le reti on-premise o di altri cloud. L'abilitazione dell'endpoint basato su DNS elimina la necessità di un bastion host o di nodi proxy per accedere al control plane da altre reti VPC o da località esterne.

Per accedere all'endpoint del control plane, devi configurare ruoli e criteri IAM e token di autenticazione. Per maggiori dettagli sulle autorizzazioni esatte richieste, vedi Personalizzare l'isolamento di rete.

Oltre a token e policy IAM, puoi configurare anche i seguenti attributi di accesso:

  • Controlli basati su indirizzi IP o rete con Controlli di servizio VPC: per migliorare la sicurezza del piano di controllo del cluster GKE, i Controlli di servizio VPC aggiungono un altro livello di sicurezza dell'accesso. Utilizza l'accesso sensibile al contesto in base ad attributi come l'origine della rete.

    Controlli di servizio VPC non supporta direttamente i cluster con indirizzi IP pubblici per il control plane. Tuttavia, i cluster GKE, inclusi quelli privati e pubblici, ottengono la protezione dei Controlli di servizio VPC quando vi accedi utilizzando l'endpoint basato su DNS.

    Configura i Controlli di servizio VPC per proteggere l'endpoint basato su DNS del cluster GKE includendo container.googleapis.com e kubernetesmetadata.googleapis.com nell'elenco dei servizi limitati del perimetro di servizio. L'aggiunta di queste API al perimetro di servizio attiverà VPC-SC per tutte le operazioni API GKE. Questa configurazione contribuisce a garantire che i perimetri di sicurezza definiti regolino l'accesso al control plane.

    Utilizzando sia i criteri IAM che i Controlli di servizio VPC per proteggere l'accesso all'endpoint basato su DNS, crei un modello di sicurezza multilivello per il control plane del cluster. I Controlli di servizio VPC si integrano con i servizi Google Cloud supportati. Allinea la configurazione di sicurezza del cluster ai dati che ospiti in altri servizi. Google Cloud

  • Private Service Connect o Cloud NAT: per accedere all'endpoint basato su DNS dai client che non hanno accesso a internet pubblico. Per impostazione predefinita, l'endpoint basato su DNS è accessibile tramite le API disponibili su internet pubblico. Google CloudPer saperne di più, consulta la sezione Endpoint basato su DNS nella pagina Personalizza l'isolamento di rete.

  • Credenziali di autenticazione Kubernetes: per l'autenticazione all'endpoint basato su DNS utilizzando token di autenticazione del servizio Kubernetes o certificati client X.509. Questi metodi di autenticazione sono disattivati per impostazione predefinita nei cluster GKE. Puoi abilitare questi metodi quando configuri l'endpoint basato su DNS per un cluster.

Endpoint basati su IP

Se vuoi, puoi anche configurare l'accesso al control plane utilizzando endpoint basati su IP.

Terminologia relativa a cluster e indirizzi IP

  • Google Cloud Indirizzi IP esterni:

    • Gli indirizzi IP esterni assegnati a qualsiasi VM utilizzata da qualsiasi cliente ospitato su Google Cloud. Google Cloud sono di proprietà di Google. Per saperne di più, consulta Dove posso trovare gli intervalli IP di Compute Engine?

    • Indirizzi IP esterni utilizzati da prodotti come Cloud Run o Cloud Run Functions. Google Cloud Qualsiasi client ospitato su Google Cloud può istanziare questi indirizzi IP. Google Cloud possiede questi indirizzi IP.

  • Indirizzi IP riservati a Google: indirizzi IP esterni per la gestione del cluster GKE. Questi indirizzi IP includono i processi gestiti di GKE e altri servizi Google di produzione. Questi indirizzi IP sono di proprietà di Google.

  • Intervalli di indirizzi IP del cluster GKE: indirizzi IP interni assegnati al cluster che GKE utilizza per i nodi, i pod e i servizi del cluster.

  • Indirizzi IP interni: indirizzi IP della rete VPC del cluster. Questi indirizzi IP possono includere l'indirizzo IP del cluster, le reti on-premise, gli intervalli RFC 1918 o gli indirizzi IP pubblici utilizzati privatamente (PUPI) che includono intervalli non RFC 1918.

  • Endpoint del cluster basato su IP esterno: l'indirizzo IP dell'endpoint esterno, che GKE assegna al control plane.

  • Indirizzo IP VM del control plane esterno: l'indirizzo IP esterno assegnato a ogni istanza VM che esegue il control plane e utilizzato solo per il traffico in uscita dal server API.

  • Endpoint interno: l'indirizzo IP interno che GKE assegna al control plane.

  • Rete VPC: una rete virtuale in cui crei subnet con intervalli di indirizzi IP specifici per i nodi e i pod del cluster.

Quando utilizzi endpoint basati su IP, hai due opzioni:

  • Esporre il control plane sia sugli endpoint esterni che su quelli interni. Ciò significa che l'endpoint esterno del control plane è accessibile da un indirizzo IP esterno e l'endpoint interno è accessibile dalla rete VPC del cluster. I nodi comunicheranno con il control plane solo sull'endpoint interno.

  • Espone il control plane solo sull'endpoint interno. Ciò significa che i client su internet non possono connettersi al cluster e il control plane è accessibile da qualsiasi indirizzo IP della rete VPC del cluster. I nodi comunicheranno con il control plane solo sull'endpoint interno.

    Questa è l'opzione più sicura quando utilizzi endpoint basati su IP, in quanto impedisce l'accesso a internet al control plane. Questa è una buona scelta se hai carichi di lavoro che, ad esempio, richiedono un accesso controllato a causa delle normative sulla privacy e sulla sicurezza dei dati.

In entrambe le opzioni precedenti, puoi limitare gli indirizzi IP che raggiungono gli endpoint configurando le reti autorizzate. Se utilizzi endpoint basati su IP, ti consigliamo vivamente di aggiungere almeno una rete autorizzata. Le reti autorizzate concedono l'accesso al control plane a un insieme specifico di indirizzi IPv4 attendibili e forniscono protezione e ulteriori vantaggi di sicurezza per il tuo cluster GKE.

Best practice:

Abilita le reti autorizzate quando utilizzi endpoint basati su IP per proteggere il cluster GKE.

Come funzionano le reti autorizzate

Le reti autorizzate forniscono un firewall basato su IP che controlla l'accesso al control plane GKE. L'accesso al control plane dipende dagli indirizzi IP di origine. Quando abiliti le reti autorizzate, configuri gli indirizzi IP per i quali vuoi consentire l'accesso all'endpoint del control plane del cluster GKE come elenco di blocchi CIDR.

La seguente tabella mostra:

  • Gli indirizzi IP preimpostati che possono sempre accedere al control plane GKE indipendentemente dal fatto che tu abiliti le reti autorizzate.
  • Gli indirizzi IP configurabili che possono accedere al control plane quando li inserisci nella lista consentita abilitando le reti autorizzate.
Endpoint del control plane Indirizzi IP preimpostati che possono sempre accedere agli endpoint Indirizzo IP configurabile che può accedere agli endpoint dopo l'attivazione delle reti autorizzate
Endpoint esterni e interni attivati
  • Indirizzi IP riservati a Google
  • Intervalli di indirizzi IP del cluster GKE
  • Indirizzi IP esterni consentiti
  • Indirizzi IP interni consentiti
  • Google Cloud indirizzi IP esterni
È abilitato solo l'endpoint interno
  • Indirizzi IP riservati a Google
  • Intervalli di indirizzi IP del cluster GKE
  • Indirizzi IP interni consentiti.

Con una rete autorizzata, puoi anche configurare la regione da cui un indirizzo IP interno può raggiungere l'endpoint interno del control plane. Puoi scegliere di consentire l'accesso solo dalla rete VPC del cluster o da qualsiasi regione Google Cloud in un ambiente VPC o on-premise.

Limitazioni dell'utilizzo di endpoint basati su IP

  • Se espandi una subnet utilizzata da un cluster con reti autorizzate, devi aggiornare la configurazione della rete autorizzata in modo da includere l'intervallo di indirizzi IP espanso.
  • Se hai client che si connettono da reti con indirizzi IP dinamici, ad esempio dipendenti su reti domestiche, devi aggiornare spesso l'elenco delle reti autorizzate per mantenere l'accesso al cluster.
  • La disabilitazione dell'accesso all'endpoint esterno del control plane impedisce l'interazione remota con il cluster. Se devi accedere in remoto al cluster, devi utilizzare un bastion host che inoltra il traffico client al cluster. Al contrario, l'utilizzo di un endpoint basato su DNS richiede solo la configurazione delle autorizzazioni IAM.
  • Gli endpoint basati su IP non si integrano direttamente con i Controlli di servizio VPC. I Controlli di servizio VPC operano a livello di perimetro di servizio per controllare l'accesso e lo spostamento dei dati all'interno di Google Cloud. Ti consigliamo di utilizzare sia un endpoint basato su DNS sia i Controlli di servizio VPC per una difesa di sicurezza efficace.
  • Puoi specificare fino a 100 intervalli di indirizzi IP autorizzati (inclusi gli indirizzi IP esterni e interni).

Accesso a origini esterne dal server API

Il control plane del cluster GKE esegue i componenti del control plane di Kubernetes, come il server API, lo scheduler e i controller. Il control plane viene eseguito su un'istanza VM di Compute Engine di proprietà di GKE in un progetto gestito. I cluster regionali e i cluster Autopilot hanno più repliche del control plane, ognuna delle quali viene eseguita sulla propria istanza VM.

Per impostazione predefinita, a ciascuna di queste istanze VM di Compute Engine è assegnato un indirizzo IP esterno direttamente alla VM. Questo indirizzo IP viene utilizzato solo per inviare richieste di ammissione dal server API Kubernetes su un'istanza ai server webhook di ammissione che vengono eseguiti al di fuori del cluster, ad esempio in un servizio cloud diverso o on-premise. Questo indirizzo IP viene utilizzato solo se i webhook di ammissione contattano direttamente il server webhook utilizzando l'URL del server o l'indirizzo IP del server.

Per migliorare la postura di sicurezza del control plane, puoi disattivare l'indirizzo IP esterno sulle istanze VM del control plane. In caso di compromissione, i potenziali malintenzionati non possono utilizzare questi indirizzi IP esterni per comunicare. Puoi personalizzare il traffico in uscita dal server API nei seguenti modi:

  • Nessun traffico in uscita (NONE): disattiva l'indirizzo IP esterno di ogni istanza del control plane e indirizza il traffico in uscita del server API a un black hole. Tutto il traffico in uscita non critico dal server API verso destinazioni esterne è bloccato, incluso il traffico verso servizi al di fuori del cluster. Google Cloud Questa opzione non influisce sul traffico di sistema critico o sul traffico dei nodi.
  • Tutto il traffico in uscita (VIA_CONTROL_PLANE): conserva l'indirizzo IP esterno di ogni istanza del control plane e consente al server API di utilizzare l'indirizzo IP per il traffico in uscita. Questa opzione è quella predefinita in GKE.

Per scoprire come personalizzare il cluster per una di queste opzioni, consulta Limitare il traffico in uscita dal server API.

Configurazione webhook esterno

Quando imposti le limitazioni in uscita del control plane su NONE, il server API non può effettuare chiamate dirette a indirizzi IP esterni o nomi di dominio completi (FQDN). L'impostazione NONE ha i seguenti effetti sugli webhook esterni:

  • Nella versione 1.35.1-gke.1396000 e successive, GKE impedisce la creazione o gli aggiornamenti di ValidatingWebhookConfigurations o MutatingWebhookConfigurations che utilizzano il campo clientConfig.url.
  • Le configurazioni webhook esistenti che utilizzano il campo clientConfig.url per contattare un server esterno smettono di funzionare.

Per creare e utilizzare server webhook esterni, devi:

  1. Aggiorna ValidatingWebhookConfigurations o MutatingWebhookConfigurations per utilizzare il campo clientConfig.service. Questo campo consente al server API di inviare richieste a un endpoint di servizio, ad esempio my-webhook.default.svc, nel tuo cluster. Queste richieste non vengono bloccate perché il traffico si trova all'interno del cluster. Per saperne di più, consulta Riferimento al servizio.

  2. Configura il servizio in modo da instradare il traffico al server webhook esterno. A seconda dei requisiti operativi e di sicurezza, puoi utilizzare uno dei seguenti progetti di routing del traffico:

    • Pod proxy: utilizza un deployment o un StatefulSet come backend per il tuo servizio. Configura i pod in modo che fungano da proxy che reindirizzano le richieste di ammissione in entrata al server webhook esterno. Questo design ti consente di eseguire attività aggiuntive, come ispezionare e modificare le richieste di ammissione.
    • EndpointSlices: crea il servizio senza un selettore, quindi aggiungi manualmente un EndpointSlice che mappa il servizio all'indirizzo IP del server webhook esterno. Questo progetto indirizza il traffico senza modificare le richieste.

Quando progetti la configurazione del webhook, considera i seguenti fattori:

  • Autenticazione e credenziali: valuta come eseguire l'autenticazione con il server webhook esterno. Il flusso di lavoro di routing del traffico deve anche gestire il modo in cui le credenziali (come chiavi API, certificati mTLS e token OAuth) vengono applicate alle connessioni.
  • Controllo di sicurezza e di rete: considera la superficie di attacco della tua progettazione del routing e le opzioni per la sicurezza e l'audit. Il design che implementi influisce sui vincoli che puoi applicare al traffico. Ad esempio, puoi utilizzare NetworkPolicies con i pod proxy.
  • Osservabilità e affidabilità: valuta come monitorare le connessioni. Ad esempio, puoi configurare i pod proxy per emettere metriche oppure puoi implementare l'osservabilità della rete per EndpointSlice.

Accesso ai nodi da origini esterne

Questa sezione descrive l'isolamento dei nodi all'interno di un cluster Kubernetes.

Abilita nodi privati

Impedisci ai client esterni di accedere ai nodi eseguendo il provisioning di questi nodi solo con indirizzi IP interni, rendendoli privati. I carichi di lavoro in esecuzione sui nodi senza un indirizzo IP esterno non possono raggiungere internet a meno che NAT non sia abilitato sulla rete del cluster. Puoi modificare queste impostazioni in qualsiasi momento.

Puoi abilitare i nodi privati a livello di singolo cluster o a livello di pool di nodi (per Standard) o di workload (per Autopilot). L'attivazione dei nodi privati a livello di pool di nodi o di workload esegue l'override di qualsiasi configurazione dei nodi a livello di cluster.

Se aggiorni un pool di nodi pubblico alla modalità privata, i carichi di lavoro che richiedono l'accesso al di fuori della rete del cluster potrebbero non riuscire nei seguenti scenari:

  • Cluster in una rete VPC condiviso in cui l'accesso privato Google non è abilitato. Abilita manualmente l'accesso privato Google per assicurarti che GKE scarichi l'immagine del nodo assegnata. Per i cluster che non si trovano in una rete VPC condiviso, GKE abilita automaticamente l'accesso privato Google.

  • Carichi di lavoro che richiedono l'accesso a internet in cui Cloud NAT non è abilitato o non è definita una soluzione NAT personalizzata. Per consentire il traffico in uscita verso internet, attiva Cloud NAT o una soluzione NAT personalizzata.

Indipendentemente dal fatto che i nodi privati siano abilitati o meno, il control plane comunica comunque con tutti i nodi solo tramite indirizzi IP interni.

Vantaggi dell'isolamento di rete

Di seguito sono riportati i vantaggi dell'isolamento di rete:

  • Flessibilità:

    • I cluster hanno una configurazione unificata e flessibile. I cluster con o senza endpoint esterni condividono la stessa architettura e supportano le stesse funzionalità. Puoi proteggere l'accesso in base a controlli e best practice che soddisfano le tue esigenze. Tutte le comunicazioni tra i nodi del cluster e il control plane utilizzano un indirizzo IP interno.
    • Puoi modificare le impostazioni di accesso al control plane e di configurazione dei nodi del cluster in qualsiasi momento senza dover ricreare il cluster.
    • Puoi scegliere di abilitare l'endpoint esterno del control plane se devi gestire il cluster da qualsiasi posizione con accesso a internet o da reti o dispositivi che non sono connessi direttamente al tuo VPC. In alternativa, puoi disattivare l'endpoint esterno per una maggiore sicurezza se devi mantenere l'isolamento della rete per i carichi di lavoro sensibili. In entrambi i casi, puoi utilizzare le reti autorizzate per limitare l'accesso a intervalli IP attendibili.

  • Sicurezza:

    • Gli endpoint basati su DNS con i Controlli di servizio VPC forniscono un modello di sicurezza multilivello che protegge il cluster da reti non autorizzate e da identità non autorizzate che accedono al control plane. I Controlli di servizio VPC si integrano con Cloud Audit Logs per monitorare l'accesso al control plane.
    • I nodi privati e i carichi di lavoro in esecuzione su questi nodi non sono direttamente accessibili da internet pubblico, il che riduce significativamente il potenziale di attacchi esterni al tuo cluster.
    • Puoi bloccare l'accesso al control plane da Google Cloud indirizzi IP esterni o da indirizzi IP esterni per isolare completamente il control plane del cluster e ridurre l'esposizione a potenziali minacce alla sicurezza.
    • Puoi disattivare gli indirizzi IP esterni delle istanze VM del control plane per impedire agli autori degli attacchi di utilizzarli.

  • Conformità: se lavori in un settore con normative rigorose per l'accesso e l'archiviazione dei dati, i nodi privati contribuiscono alla conformità garantendo che i dati sensibili rimangano all'interno della tua rete privata.

  • Controllo: i nodi privati ti offrono un controllo granulare sul flusso di traffico in entrata e in uscita dal cluster. Puoi configurare regole firewall e policy di rete per consentire solo la comunicazione autorizzata. Se operi in ambienti multi-cloud, i nodi privati possono aiutarti a stabilire una comunicazione sicura e controllata tra i diversi ambienti.

  • Costo: se abiliti i nodi privati, puoi ridurre i costi per i nodi che non richiedono un indirizzo IP esterno per accedere ai servizi pubblici su internet.

Passaggi successivi