Sicurezza del piano di controllo

Questo documento descrive in che modo Google Kubernetes Engine (GKE) protegge i componenti del piano di controllo del cluster.

In Modello di responsabilità condivisa, Google gestisce i componenti del piano di controllo GKE per conto tuo. Il piano di controllo include il server API Kubernetes, l'archiviazione etcd e altri controller. Google è responsabile della sicurezza del piano di controllo, anche se potresti essere in grado di configurare determinate opzioni in base ai tuoi requisiti. Sei responsabile della sicurezza di nodi, container e pod.

Sistema operativo protetto

I componenti del piano di controllo GKE vengono eseguiti in Container-Optimized OS, un sistema operativo con sicurezza avanzata e progettato da Google. Per una descrizione dettagliata delle funzionalità di sicurezza integrate in Container-Optimized OS, consulta la Panoramica sulla 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 maggiori dettagli su come i componenti del cluster si autenticano tra loro, consulta Affidabilità del cluster.

Accesso del piano di controllo al progetto

GKE utilizza un account di servizio gestito da Google denominato agente di servizio Kubernetes Engine per attivare le risorse cluster per tuo conto, ad esempio nodi, dischi e bilanciatori del carico. All'account di servizio viene assegnato automaticamente il ruolo Agente di servizio Kubernetes Engine (roles/container.serviceAgent) per il 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 numero del tuo progetto.

Accesso amministrativo al cluster

Le sessioni SSH degli ingegneri di Google Site Reliability vengono controllate tramite l'infrastruttura di audit interna di Google, disponibile per l'analisi forense e la risposta di sicurezza. Per ulteriori informazioni, consulta la sezione Accesso amministrativo nel white paper sulla sicurezza di Google.

sicurezza etcd

Per impostazione predefinita, in Google Cloud i contenuti dei clienti vengono criptati a livello di file system. Di conseguenza, i dischi che ospitano l'archiviazione etcd per i cluster GKE sono criptati a livello di file system. Per maggiori informazioni, consulta Crittografia at-rest.

etcd rimane in ascolto su due porte TCP. La porta 2379 è per i client etcd, come il server API Kubernetes. La porta 2379 è associata all'interfaccia di rete di loopback locale, quindi è accessibile solo dalla VM che esegue il server API Kubernetes. La porta 2380 è per la comunicazione server-server. Il traffico sulla porta 2380 è criptato tramite TLS reciproco. In altre parole, ogni server deve dimostrare la propria identità all'altro. In un cluster a livello di regione, le comunicazioni tra i server etcd per stabilire un quorum sono criptate da TLS reciproco.

Autorità di certificazione e attendibilità del cluster

Ogni cluster ha la propria autorità di certificazione (CA) principale. Un servizio Google interno gestisce le chiavi radice per questa CA. Ogni cluster dispone anche di una propria CA per etcd. Le chiavi radice della CA etcd vengono distribuite nei metadati delle VM che eseguono il server API Kubernetes. La comunicazione tra i nodi e il server API Kubernetes è protetta tramite TLS. Per ulteriori informazioni, consulta Affidabilità dei cluster.

Vulnerabilità e gestione delle patch

GKE aderisce agli standard di Google per i test, l'idoneità e l'implementazione graduale delle modifiche al piano di controllo. Questo riduce al minimo il rischio che un componente del piano di controllo diventi non disponibile. GKE ottempera a un accordo sul livello del servizio che definisce molti aspetti della disponibilità.

I componenti del piano di controllo GKE sono gestiti da un team di Site Reliability Engineer di Google e sono sempre aggiornati con le patch di sicurezza più recenti. Ciò include le patch del sistema operativo host, dei componenti Kubernetes e dei container in esecuzione sulle VM del piano di controllo.

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

Gli ingegneri di Google contribuiscono a trovare, correggere e divulgare i bug di sicurezza di Kubernetes. Inoltre, tramite il programma Vulnerability Reward Program di Google, Google corrisponde a ricercatori esterni nel campo della sicurezza la ricerca di bug di sicurezza. In alcuni casi, ad esempio per la vulnerabilità dnsmasq nell'ottobre 2017, GKE è riuscito ad applicare la patch a tutti i cluster in esecuzione prima che la vulnerabilità diventasse pubblica.

Informazioni visibili

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

L'audit logging è abilitato per impostazione predefinita per i cluster creati a partire dalla versione 1.8.3 di GKE. Fornisce un record dettagliato, disponibile in Observability di Google Cloud, delle chiamate effettuate al server API Kubernetes. Puoi visualizzare le voci di log in Esplora log nella console Google Cloud. Puoi anche utilizzare BigQuery per visualizzare e analizzare questi log.

Cosa puoi configurare

Per impostazione predefinita, il server API Kubernetes utilizza un indirizzo IP pubblico. Puoi proteggere il server API Kubernetes utilizzando reti autorizzate e cluster privati, che ti consentono di assegnare un indirizzo IP privato al server API Kubernetes e disabilitare l'accesso sull'indirizzo IP pubblico.

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 per i cluster creati con GKE versione 1.12 e successive.

Puoi migliorare la sicurezza del tuo piano di controllo eseguendo regolarmente la rotazione delle credenziali. Quando viene avviata la rotazione delle credenziali, i certificati TLS e l'autorità di certificazione del cluster vengono ruotati automaticamente. Inoltre, GKE ruota l'indirizzo IP del server API Kubernetes. Per maggiori informazioni, consulta Controllo degli accessi basato sui ruoli (RBAC) e Rotazione delle credenziali.

Passaggi successivi