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.

In base al 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 su istanze Compute Engine di proprietà di Google, in un progetto gestito da Google. Ogni istanza esegue questi componenti solo per un cluster.

Per maggiori dettagli su come i componenti del cluster si autenticano tra loro, consulta Affidabilità del cluster.

Controlla l'accesso al control plane al tuo 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. All'account di servizio viene assegnato automaticamente il ruolo Agente di servizio Kubernetes Engine (roles/container.serviceAgent) nel 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 è in ascolto su due porte TCP. La porta 2379 è per i client etcd, ad esempio il server API Kubernetes. La porta 2379 è associata all'interfaccia di rete loopback locale, pertanto è accessibile solo dalla VM su cui è in esecuzione il server API Kubernetes. La porta 2380 è per la comunicazione server-to-server. Il traffico sulla porta 2380 è criptato da TLS reciproco. In altre parole, ogni server deve dimostrare la sua identità l'altra. In un cluster regionale, la comunicazione tra i server etcd per stabilire un quorum è criptata da TLS reciproco.

Autorità di certificazione e attendibilità 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. Ogni cluster ha anche una propria CA per etcd. Le chiavi principali per la CA etcd vengono distribuite ai 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 un componente del piano di controllo non sia disponibile. GKE rispetta 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 le patch per il sistema operativo host, i componenti Kubernetes 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 per vulnerabilità note, sono disponibili ulteriori informazioni nei 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 ricercatori esterni nel campo della sicurezza, tramite il Vulnerability Reward Program di Google, per cercare bug di sicurezza. In alcuni casi, come la vulnerabilità dnsmasq di ottobre 2017, GKE è stato in grado di applicare patch a tutti i cluster in esecuzione prima che la vulnerabilità diventasse di dominio pubblico.

Informazioni visibili

Le funzionalità di sicurezza discusse 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: Audit log è abilitata per impostazione predefinita. Viene fornito un record dettagliato, disponibile in Google Cloud Observability, delle chiamate effettuate al server dell'API Kubernetes. Puoi visualizzare il log in Esplora log nel nella console Google Cloud. Puoi anche utilizzare BigQuery per visualizzare e analizzare questi log.

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

    Per eseguire la verifica dell'integrità della VM, consulta Verifica l'integrità della VM del piano di controllo GKE.

Cosa puoi configurare

Sebbene GKE gestisca la maggior parte del piano di controllo per te, puoi controllare quanto segue:

  • Accesso al piano di controllo: 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 disattivare l'accesso sull'indirizzo IP pubblico.
  • Autenticazione: puoi gestire l'autenticazione del cluster in GKE utilizzando IAM come provider di identità. Per sicurezza dell'autenticazione avanzata, autenticazione di base e certificato client l'emissione è disattivata 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 esegue anche la rotazione dell'indirizzo IP del server API Kubernetes durante questa procedura. Per ulteriori informazioni, consulta la sezione sulla rotazione delle credenziali.

Inoltre, se la tua organizzazione ha requisiti rigorosi per la conformità o le norme relative al piano di controllo, l'autorità del piano di controllo GKE è un insieme che offrono visibilità e controllo avanzati su specifici degli aspetti del piano di controllo, tra cui:

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

Per informazioni dettagliate sul motivo per cui potresti utilizzare queste funzionalità e per tutte disponibili, vedi Informazioni sull'autorità del piano di controllo GKE.

Passaggi successivi