Sicurezza del piano di controllo

Questa pagina descrive in che modo Google Kubernetes Engine (GKE) protegge i componenti del control plane del cluster. Scopri le funzionalità di sicurezza integrate in GKE, che includono un sistema operativo con sicurezza avanzata, un'architettura e un isolamento robusti, un accesso sicuro al control plane, la sicurezza per il database dello stato del cluster basato su etcd o Spanner, l'autorità di certificazione e l'attendibilità del cluster, nonché la gestione di vulnerabilità e patch.

Questa pagina è rivolta agli specialisti della sicurezza che vogliono capire come Google gestisce i componenti del control plane di GKE e le misure di sicurezza in atto per valutare efficacemente il rischio e garantire la sicurezza delle implementazioni GKE. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività comuni degli utenti di GKE Enterprise. Google Cloud

In base al modello di responsabilità condivisa, Google gestisce i componenti del control plane GKE per te. Il control plane include il server API Kubernetes, l'archiviazione degli oggetti API Kubernetes e altri controller. Google è responsabile della protezione del control plane, anche se potresti essere in grado di configurare determinate opzioni in base ai tuoi requisiti. Sei responsabile della protezione di nodi, container e pod.

Sistema operativo protetto

I componenti del piano di controllo GKE vengono eseguiti su Container-Optimized OS, un sistema operativo con protezione avanzata progettato da Google. Per una descrizione dettagliata delle funzionalità di sicurezza integrate in Container-Optimized OS, consulta la panoramica della sicurezza di Container-Optimized OS.

Architettura e isolamento

In un cluster GKE, i componenti del piano di controllo vengono eseguiti su istanze Compute Engine di proprietà di Google, in un progetto gestito da Google. Ogni istanza esegue questi componenti per un solo cluster.

Per informazioni dettagliate su come i componenti del cluster si autenticano a vicenda, vedi Attendibilità del cluster.

Accesso del control plane al tuo progetto

GKE utilizza un service agent denominato Kubernetes Engine Service Agent per attivare le risorse del cluster per tuo conto, come nodi, dischi e bilanciatori del carico. All'account di servizio viene concesso automaticamente il ruolo Agente di servizio Kubernetes Engine (roles/container.serviceAgent) sul tuo progetto.

L'agente di servizio Kubernetes Engine ha il seguente indirizzo email:

service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

In questo indirizzo email, PROJECT_NUMBER è il tuo numero di progetto.

Accesso amministrativo al cluster

Le sessioni SSH degli ingegneri SRE di Google vengono registrate tramite l'infrastruttura di controllo interna di Google, disponibile per l'analisi forense e la risposta alla sicurezza. Per saperne di più, vedi Accesso amministrativo nel white paper sulla sicurezza di Google.

Sicurezza del database dello stato del cluster

In Google Cloud, i contenuti dei clienti sono criptati per impostazione predefinita a livello di file system. Questa crittografia include l'infrastruttura che ospita il database basato su etcd o Spanner che memorizza lo stato degli oggetti API Kubernetes nel tuo cluster. Per saperne di più sul database dello stato del cluster, consulta Architettura del cluster GKE.

Il database dello stato del cluster memorizza la configurazione di ogni oggetto API Kubernetes nel cluster come coppie chiave-valore. GKE utilizza porte TCP specifiche sulle VM del piano di controllo per i seguenti tipi di comunicazione con il database dello stato del cluster:

  • Client API etcd: GKE gestisce l'API etcd su ogni VM del control plane. I client API etcd nel control plane, come il server API Kubernetes, utilizzano una delle seguenti porte:

    • Porta 2379: questa porta viene utilizzata quando GKE archivia lo stato del cluster nelle istanze del database etcd in esecuzione in ogni VM del control plane.
    • Porta 3379: questa porta viene utilizzata quando GKE archivia lo stato del cluster in un database Spanner separato dal piano di controllo.

    La porta utilizzata dai client API etcd è associata all'interfaccia di rete loopback locale ed è accessibile solo dalla VM del control plane che esegue il server API Kubernetes.

  • Istanze del database etcd: se le VM del control plane eseguono istanze del database etcd, i server API etcd su ogni VM utilizzano la porta 2380 per comunicare tra loro. Il traffico sulla porta 2380 tra le istanze del database etcd su più VM del control plane (ad esempio nei cluster regionali) viene criptato mediante TLS reciproco. Con TLS reciproco, ogni server deve dimostrare la propria identità all'altro.

    La porta 2380 non viene utilizzata nei cluster che archiviano lo stato del cluster in un database Spanner perché il database non viene eseguito nelle VM del control plane.

Autorità di certificazione e attendibilità del cluster

Ogni cluster ha la propria autorità di certificazione (CA) radice. Le chiavi radice di questa CA vengono gestite da un servizio interno di Google. Le chiavi radice di questa CA vengono distribuite ai metadati delle VM che eseguono il server API Kubernetes. La comunicazione tra i nodi e il server API Kubernetes è protetta da TLS. Ogni cluster ha anche una propria CA per l'API etcd e, se il cluster esegue istanze del database etcd, per il traffico tra le istanze etcd. Per ulteriori informazioni, vedi Affidabilità del cluster.

Gestione delle vulnerabilità e delle patch

GKE rispetta gli standard di Google per il test, la qualifica e l'implementazione graduale delle modifiche al control plane. In questo modo si riduce al minimo il rischio che un componente del piano di controllo diventi non disponibile. GKE rispetta un accordo sul livello del servizio che definisce molti aspetti della disponibilità.

I componenti del control plane GKE sono gestiti da un team di Site Reliability Engineer di Google e vengono mantenuti aggiornati con le patch di sicurezza più recenti. Sono incluse le patch per il sistema operativo host, i componenti Kubernetes e i container in esecuzione sulle VM del piano di controllo.

GKE applica tempestivamente nuove correzioni a livello di kernel, sistema operativo e Kubernetes alle VM del control plane. Quando contengono correzioni per vulnerabilità note, sono disponibili informazioni aggiuntive nei bollettini sulla sicurezza di GKE. GKE esegue la scansione di tutti i container di sistema Kubernetes e specifici di GKE per rilevare vulnerabilità utilizzando Artifact Analysis e mantiene le patch dei container, a vantaggio dell'intero ecosistema Kubernetes.

Gli ingegneri di Google partecipano alla ricerca, alla correzione e alla divulgazione dei bug di sicurezza di Kubernetes. Google paga anche ricercatori esterni nel campo della sicurezza, tramite il Vulnerability Reward Program di Google, per la ricerca di bug di sicurezza. In alcuni casi, ad esempio la vulnerabilità dnsmasq di ottobre 2017, GKE è riuscito a correggere tutti i cluster in esecuzione prima che la vulnerabilità diventasse pubblica.

Cosa puoi vedere

Le funzionalità di sicurezza descritte in precedenza in questo argomento sono gestite da Google. Questa sezione e la successiva descrivono le funzionalità di sicurezza che puoi monitorare e configurare.

  • Audit log: l'audit logging è abilitato per impostazione predefinita. In questo modo viene fornito un record dettagliato, disponibile in Google Cloud Observability, delle chiamate effettuate al server dell'API Kubernetes. Puoi visualizzare le voci di log in Esplora log nella consoleGoogle Cloud . Puoi anche utilizzare BigQuery per visualizzare e analizzare questi log.

  • Integrità dell'immagine VM del control plane: GKE aggiunge log dettagliati per gli eventi di creazione e avvio delle VM dei nodi a Cloud Logging. Inoltre, pubblichiamo VSA SLSA su GitHub corrispondenti alle immagini macchina del control plane e dei nodi worker. Puoi verificare che le tue VM utilizzino immagini del sistema operativo con VSA corrispondenti e verificare l'integrità di avvio di ogni VM del control plane.

    Per eseguire la verifica dell'integrità della VM, consulta Verifica l'integrità della VM del control plane GKE.

Cosa puoi configurare

Anche se GKE gestisce la maggior parte del control plane per te, puoi controllare quanto segue:

  • Accesso al control plane: il control plane ha due tipi di endpoint per l'accesso al cluster:

    • Endpoint basato sul DNS
    • Endpoint basati su IP

    Per impostazione predefinita, il server API Kubernetes utilizza un indirizzo IP esterno. Puoi proteggere il server API Kubernetes abilitando un endpoint basato su DNS per l'accesso al control plane. Puoi controllare chi può accedere all'endpoint DNS con i Controlli di servizio VPC, che ti consentono di definire un parametro di sicurezza per tutte le API di Google nel tuo progetto. Se utilizzi endpoint basati su IP per l'accesso al control plane, ti consigliamo di utilizzare reti autorizzate e disabilitare l'accesso all'endpoint esterno del control plane. Per saperne di più sull'isolamento di rete, consulta Informazioni sulla personalizzazione dell'isolamento di rete.

  • Autenticazione: puoi gestire l'autenticazione del cluster in GKE utilizzando IAM come provider di identità. Per una maggiore sicurezza dell'autenticazione, l'autenticazione di base e l'emissione di certificati client sono disabilitate per impostazione predefinita.

  • Rotazione delle credenziali: ruota regolarmente l'autorità di certificazione (CA) e i certificati TLS del cluster eseguendo una rotazione delle credenziali. GKE ruota anche l'indirizzo IP del server API Kubernetes durante questo processo. Per ulteriori informazioni, consulta la sezione Rotazione delle credenziali.

Inoltre, se la tua organizzazione ha requisiti rigorosi di conformità o criteri relativi al control plane, l'autorità del control plane GKE è un insieme di funzionalità che ti offrono maggiore visibilità e controllo su aspetti specifici del control plane, tra cui:

  • Esegui le tue CA e le tue chiavi per l'emissione di identità utilizzando Cloud KMS e CA Service.
  • Cripta i dischi di avvio di etcd e del control plane utilizzando le tue chiavi in Cloud KMS.

Per informazioni dettagliate sul motivo per cui utilizzare queste funzionalità e su tutte le funzionalità disponibili, consulta Informazioni sull'autorità del control plane GKE.

Passaggi successivi