Sicurezza

Questa pagina descrive le funzionalità di sicurezza incluse in Google Distributed Cloud, compreso ogni livello della sua infrastruttura, e come puoi configurarle in base alle tue esigenze.

Panoramica

GKE on VMware offre diverse funzionalità per proteggere i carichi di lavoro, inclusi i contenuti dell'immagine container, il runtime del container, la rete cluster e l'accesso al server API del cluster.

È meglio adottare un approccio a più livelli per proteggere i cluster e i carichi di lavoro. Puoi applicare il principio del privilegio minimo al livello di accesso che fornisci a utenti e carichi di lavoro. Potresti dover scendere a compromessi per garantire il giusto livello di flessibilità e sicurezza.

Autenticazione e autorizzazione

Per l'autenticazione nei cluster GKE on VMware, utilizza OpenID Connect (OIDC) o un token dell'account di servizio Kubernetes tramite la console Cloud.

Per configurare un accesso più granulare alle risorse Kubernetes a livello di cluster o all'interno degli spazi dei nomi Kubernetes, utilizza il controllo degli accessi basato sui ruoli (RBAC) di Kubernetes. RBAC ti consente di creare criteri dettagliati che definiscono le operazioni e le risorse a cui vuoi consentire l'accesso da parte di utenti e account di servizio. Con RBAC, puoi controllare l'accesso per qualsiasi identità convalidata fornita.

Per semplificare e ottimizzare ulteriormente la strategia di autenticazione e autorizzazione per Kubernetes Engine, GKE on VMware disabilita il controllo degli accessi basato su attributi (ABAC) legacy.

Sicurezza del piano di controllo

I componenti del piano di controllo includono il server API, lo scheduler, i controller e il database etcd di Kubernetes in cui è permanente la configurazione di Kubernetes. Mentre in Kubernetes Engine, i componenti del piano di controllo Kubernetes sono gestiti e gestiti da Google, gli amministratori locali gestiscono i componenti del piano di controllo in GKE on VMware.

In GKE on VMware, i componenti del piano di controllo vengono eseguiti all'interno della rete aziendale. Puoi proteggere il server API di GKE on VMware utilizzando i firewall e i criteri di rete aziendali esistenti. Puoi anche assegnare un indirizzo IP privato al server API e limitare l'accesso all'indirizzo privato.

Tutte le comunicazioni in GKE su VMware avvengono su canali TLS, regolati da tre autorità di certificazione (CA): etcd, cluster e organizzazione:

  • La CA etcd protegge la comunicazione dal server API alle repliche etcd, nonché il traffico tra le repliche etcd. Questa CA è autofirmata.
  • La CA del cluster protegge le comunicazioni tra il server API e tutti i client API Kubernetes interni (kubelet, controller, scheduler). Questa CA è autofirmata.
  • La CA dell'organizzazione è una CA esterna utilizzata per gestire l'API Kubernetes per gli utenti esterni. Sei tu a gestire questa CA.

Per i piani di controllo amministrativi, le chiavi vengono archiviate nel nodo del piano di controllo. Per i cluster utente, le chiavi vengono archiviate come secret Kubernetes nel piano di controllo amministratore. Il server API è configurato con un certificato fornito dall'utente firmato dalla CA dell'organizzazione. Il server API utilizza l'indicazione del nome del server (SNI) per determinare se utilizzare la chiave firmata dalla CA del cluster o dalla chiave firmata dalla CA dell'organizzazione.

L'autenticazione dei cluster in GKE on VMware è gestita da certificati e token di connessione degli account di servizio. In qualità di amministratore, puoi eseguire l'autenticazione al piano di controllo utilizzando OIDC o con il certificato amministrativo (che utilizzi per la creazione iniziale dell'associazione dei ruoli o per scopi di emergenza).

La rotazione dei certificati viene gestita nei seguenti modi:

  • Per il server API, i piani di controllo e i nodi, i certificati vengono creati o ruotati a ogni upgrade.
  • Le CA possono essere ruotate raramente o on demand.

Sicurezza dei nodi

GKE on VMware esegue il deployment dei carichi di lavoro in istanze VMware, che sono collegate ai cluster come nodi. Le sezioni seguenti mostrano come sfruttare le funzionalità di sicurezza a livello di nodo disponibili in GKE on VMware.

Ubuntu

GKE on VMware utilizza una versione ottimizzata di Ubuntu come sistema operativo su cui eseguire il piano di controllo e i nodi Kubernetes. Ubuntu include un ricco set di funzionalità di sicurezza moderne e GKE on VMware implementa diverse funzionalità di miglioramento della sicurezza per i cluster, tra cui:

Sono disponibili ulteriori guide alla sicurezza per Ubuntu, come:

Upgrade dei nodi

Dovresti eseguire l'upgrade dei nodi regolarmente. A volte, i problemi di sicurezza nel runtime del container, in Kubernetes stesso o nel sistema operativo dei nodi potrebbero richiedere un upgrade più urgente dei nodi. Quando esegui l'upgrade del cluster, viene eseguito l'upgrade del software di ogni nodo alle versioni più recenti.

Protezione dei carichi di lavoro

Kubernetes consente agli utenti di eseguire rapidamente il provisioning, la scalabilità e l'aggiornamento dei carichi di lavoro basati su container. Questa sezione descrive le tattiche che amministratori e utenti possono utilizzare per limitare la capacità dei container in esecuzione di influire su altri container nel cluster, sugli host su cui vengono eseguiti e sui servizi Google Cloud abilitati nel loro progetto.

Limitazione dei privilegi di processo del container di pod

Limitare i privilegi dei processi containerizzati è importante per la sicurezza generale del cluster. Kubernetes Engine consente di impostare le opzioni relative alla sicurezza tramite il contesto di sicurezza su pod e container. Queste impostazioni consentono di modificare le impostazioni di sicurezza dei processi, ad esempio:

  • Utente e gruppo da usare per l'esecuzione.
  • Funzionalità Linux disponibili.
  • Escalation dei privilegi.

Il sistema operativo predefinito GKE on VMware, Ubuntu, applica i criteri di sicurezza di Docker AppArmor predefiniti a tutti i container avviati da Kubernetes. Puoi visualizzare il modello del profilo su GitHub. Tra le altre cose, il profilo nega le seguenti capacità per i container:

  • Scrittura nei file direttamente in una directory ID di processo (/proc/).
  • Scrittura su file che non si trovano in /proc/.
  • Scrittura in file in /proc/sys diversi da /proc/sys/kernel/shm*.
  • Montaggio dei file system.

Audit logging

L'audit logging di Kubernetes consente agli amministratori di conservare, eseguire query, elaborare e creare avvisi sugli eventi che si verificano nei tuoi ambienti GKE on VMware. Gli amministratori possono utilizzare le informazioni registrate per eseguire analisi forensi, avvisi in tempo reale o per catalogare come un parco risorse di cluster Kubernetes Engine viene utilizzato e da chi.

Per impostazione predefinita, GKE on VMware registra l'attività di amministrazione. Facoltativamente, puoi anche registrare gli eventi di accesso ai dati, a seconda dei tipi di operazioni che ti interessa esaminare.

L'agente Connect comunica solo con il server API locale in esecuzione on-premise e ogni cluster deve avere il proprio set di audit log. Tutte le azioni eseguite dagli utenti dalla UI tramite Connect vengono registrate nel cluster.

Crittografia

Se i cluster e i carichi di lavoro GKE on VMware si connettono in modo sicuro ai servizi Google Cloud tramite Cloud VPN, puoi utilizzare Cloud Key Management Service (Cloud KMS) per la gestione delle chiavi. Cloud KMS è un Key Management Service ospitato nel cloud che consente di gestire le chiavi di crittografia per i servizi. Puoi generare, utilizzare, ruotare ed eliminare chiavi di crittografia AES256, RSA 2048, RSA 3072, RSA 4096, EC P256 ed EC P384. Cloud KMS è integrato con Identity and Access Management (IAM) e Cloud Audit Logging per consentirti di gestire le autorizzazioni per le singole chiavi e monitorarne l'utilizzo. Utilizza Cloud KMS per proteggere i secret e altri dati sensibili che devi archiviare. In caso contrario, puoi scegliere una delle seguenti alternative:

  • Secret di Kubernetes
  • Hashicorp Vault
  • HSM della rete Thales Luna
  • Modulo di sicurezza hardware (HSM) di Google Cloud

Secret di Kubernetes

Le risorse Secret di Kubernetes archiviano dati sensibili, come password, token OAuth e chiavi SSH, nei tuoi cluster. L'archiviazione dei dati sensibili in Secret è più sicura rispetto all'archiviazione in testo non crittografato ConfigMaps o nelle specifiche dei pod. L'utilizzo dei secret ti consente di controllare come vengono utilizzati i dati sensibili e riduce il rischio di esposizione dei dati a utenti non autorizzati.

Hashicorp Vault

Modulo di sicurezza hardware