Sicurezza del piano di controllo

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

Nella sezione Modello di responsabilità condivisa, Google gestisce per te i componenti del piano di controllo GKE. La il piano di controllo include il server API Kubernetes, l'archiviazione etcd e altre controller. Google è responsabile della sicurezza del piano di controllo, anche se potrebbe essere in grado di configurare determinate opzioni in base ai tuoi requisiti. Stai responsabile della sicurezza di nodi, container e pod.

Sistema operativo protetto

I componenti del piano di controllo GKE vengono eseguiti Container-Optimized OS un sistema operativo rafforzato dalla sicurezza progettato da Google. Per una panoramica descrizione 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 Istanze Compute Engine di proprietà di Google, in un progetto gestito da Google. Ciascuna in esecuzione 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 al piano di controllo al progetto

GKE utilizza un cluster agente di servizio denominato l'agente di servizio Kubernetes Engine per attivare le risorse del cluster come nodi, dischi e bilanciatori del carico. L'account di servizio è ha concesso automaticamente 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 dei Site Reliability Engineer di Google vengono registrate L'infrastruttura di audit interna di Google, disponibile per analisi risposta di sicurezza. Per ulteriori informazioni, consulta Accesso amministrativo. nel whitepaper sulla sicurezza di Google.

sicurezza etcd

In Google Cloud, i contenuti dei clienti sono criptati a livello di file system predefinito. Di conseguenza, i dischi che ospitano l'archiviazione etcd per i cluster GKE sono crittografati a livello di file system. Per ulteriori informazioni, vedi Crittografia at-rest.

etcd ascolta su due porte TCP. La porta 2379 è per i client etcd, ad esempio il server API Kubernetes. La porta 2379 è associata alla rete di loopback locale in modo che sia accessibile solo dalla VM che esegue Kubernetes API di Google Cloud. La porta 2380 è per la comunicazione server-to-server. Traffico sulla porta 2380 è criptato da TLS reciproco. In altre parole, ogni server deve dimostrare la sua identità l'altra. In un cluster a livello di regione, la comunicazione tra i server etcd per stabilire un quorum è criptato TLS reciproca.

Autorità di certificazione e attendibilità cluster

Ogni cluster ha il proprio autorità di certificazione (CA) radice. Un servizio Google interno gestisce le chiavi principali per questa CA. Ogni cluster ha anche la propria CA per etcd. Le chiavi radice per la CA etcd sono e la distribuzione nei metadati delle VM che eseguono il server API Kubernetes. La comunicazione tra i nodi e il server API di Kubernetes è protetta tramite TLS. Per ulteriori informazioni, vedi Affidabilità del cluster.

Vulnerabilità e gestione delle patch

GKE aderisce agli standard Google per i test, le implementando gradualmente le modifiche al piano di controllo. In questo modo si riduce al minimo il rischio che il componente del piano di controllo non è più disponibile. GKE aderisce 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 tecnici della Site Reliability Engineering e sono costantemente aggiornati con le più recenti patch. Sono incluse patch per il sistema operativo host, Kubernetes i componenti e i container in esecuzione sulle VM del piano di controllo.

GKE applica correzioni a livello di kernel, sistema operativo e Kubernetes per le VM del piano di controllo. Se contengono correzioni vulnerabilità, sono disponibili ulteriori informazioni nel Bollettini sulla sicurezza di GKE. GKE analizza tutti i sistemi Kubernetes per i container specifici GKE per le vulnerabilità Artifact Analysis e mantiene i container con le patch, a vantaggio dell'intero ecosistema Kubernetes.

I tecnici di Google contribuiscono alla ricerca, alla correzione e alla divulgazione di di sicurezza. Google paga anche i ricercatori esterni nel campo della sicurezza, attraverso il Vulnerability Reward Program di Google, alla ricerca di bug di sicurezza. In alcuni casi, ad esempio vulnerabilità dnsmasq nell'ottobre 2017, GKE è riuscito ad applicare patch a tutti prima che la vulnerabilità diventasse pubblica.

Che cosa puoi vedere

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

Log di controllo è abilitato per impostazione predefinita per i cluster creati a partire dalla versione di GKE 1.8.3. Fornisce un registro dettagliato, disponibile in Google Cloud Observability, delle chiamate effettuate al server API Kubernetes. Puoi visualizzare le voci di log nel 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 i cluster privati, 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 l'autenticazione avanzata di sicurezza, l'autenticazione di base e l'emissione di certificati client sono disattivate predefinita per i cluster creati con GKE 1.12 e versioni successive.

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

Passaggi successivi