Sicurezza

Questa pagina descrive le funzionalità di sicurezza incluse in GKE su VMware, compreso ogni livello della sua infrastruttura, e come puoi configurare queste funzionalità di sicurezza in base alle tue esigenze.

Panoramica

GKE su VMware offre diverse funzionalità per contribuire a proteggere i tuoi carichi di lavoro, tra cui i contenuti dell'immagine container, il runtime del container, la rete cluster e l'accesso al server API del cluster.

È preferibile adottare un approccio a più livelli per la protezione dei cluster e dei 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

Puoi eseguire l'autenticazione nei cluster GKE su VMware utilizzando 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 di Kubernetes, utilizza il controllo degli accessi basato su ruoli (RBAC) di Kubernetes. RBAC consente di creare criteri dettagliati che definiscono le operazioni e le risorse che vuoi consentire a utenti e account di servizio di accedere. 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 su 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. In Kubernetes Engine, invece, i componenti del piano di controllo Kubernetes sono gestiti e gestiti da Google, mentre gli amministratori locali gestiscono i componenti del piano di controllo in GKE su VMware.

In GKE su VMware, i componenti del piano di controllo vengono eseguiti all'interno della rete aziendale. Puoi proteggere il server API di GKE su VMware utilizzando i criteri di rete e i firewall 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 tramite canali TLS, regolati da tre autorità di certificazione (CA): etcd, cluster e org:

  • La CA etcd protegge la comunicazione dal server API alle repliche etcd e anche 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 fornire l'API Kubernetes a utenti esterni. Gestisci 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 di Kubernetes nel piano di controllo di amministrazione. Il server API è configurato con un certificato fornito dall'utente firmato dalla CA dell'organizzazione. Il server API utilizza l'indicazione del nome server (SNI) per determinare se utilizzare la chiave firmata dalla CA del cluster o dalla CA dell'organizzazione.

L'autenticazione dei cluster in GKE su VMware è gestita da certificati e token di connessione degli account di servizio. In qualità di amministratore, esegui l'autenticazione sul 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 modi seguenti:

  • 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 su VMware esegue il deployment dei carichi di lavoro in istanze VMware, collegate ai cluster come nodi. Le sezioni seguenti mostrano come sfruttare le funzionalità di sicurezza a livello di nodo disponibili in GKE su VMware.

Ubuntu

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

Sono disponibili guide aggiuntive alla sicurezza per Ubuntu, ad esempio:

Upgrade dei nodi

Dovresti eseguire regolarmente l'upgrade dei nodi. Di tanto in tanto, per problemi di sicurezza relativi al runtime del container, a Kubernetes stesso o al sistema operativo dei nodi, è possibile che tu debba eseguire l'upgrade dei nodi con maggiore urgenza. Quando esegui l'upgrade del cluster, il software di ogni nodo viene aggiornato 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 del processo per i container dei pod

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

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

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

  • Scrittura nei file direttamente in una directory di ID di processo (/proc/).
  • Scrittura in file non presenti in /proc/.
  • Scrittura in file in /proc/sys diverso 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 inviare avvisi sugli eventi che si verificano nei tuoi ambienti GKE su VMware. Gli amministratori possono utilizzare le informazioni registrate per effettuare analisi forensi, avvisi in tempo reale o per catalogare come e da chi viene utilizzato un parco risorse di cluster Kubernetes Engine.

Per impostazione predefinita, l'attività di amministrazione dei log di GKE su VMware. Facoltativamente, puoi anche registrare gli eventi di accesso ai dati, a seconda dei tipi di operazioni che vuoi ispezionare.

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 dall'interfaccia utente tramite Connect vengono registrate da quel cluster.

Crittografia

Se i cluster e i carichi di lavoro GKE su 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 le 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 Logs in modo che tu possa gestire le autorizzazioni per le singole chiavi e monitorare come vengono utilizzate. Utilizza Cloud KMS per proteggere i secret e altri dati sensibili che è necessario archiviare. In caso contrario, puoi scegliere di utilizzare una delle seguenti alternative:

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

Secret di Kubernetes

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

Hashicorp Vault

Modulo di sicurezza hardware