Sicurezza

Il software Google Distributed Cloud solo per VMware include funzionalità di sicurezza che ti aiutano a proteggere ogni livello della tua infrastruttura, dall'accesso al cluster e dal control plane ai nodi e ai workload. Puoi combinare autenticazione e autorizzazione, sicurezza del control plane e dei nodi, restrizioni dei workload, audit logging e crittografia in una difesa a più livelli per i tuoi cluster.

Panoramica

Google Distributed Cloud solo software per VMware offre diverse funzionalità per proteggere i tuoi workload, tra cui i contenuti dell'immagine container, il runtime del container, la rete del cluster e l'accesso al server API del cluster.

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

Autenticazione e autorizzazione

L'autenticazione ai cluster avviene tramite OpenID Connect (OIDC) o un token del service account 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 policy dettagliate che definiscono le operazioni e le risorse a cui vuoi consentire l'accesso agli utenti e ai service account. Con RBAC, puoi controllare l'accesso per qualsiasi identità convalidata fornita.

Per semplificare e ottimizzare ulteriormente la tua strategia di autenticazione e autorizzazione per Kubernetes Engine, Google Distributed Cloud disattiva il controllo dell'accesso basato su attributi (ABAC) legacy.

Sicurezza del control plane

I componenti del control plane includono il server API Kubernetes, lo scheduler, i controller e il database etcd in cui viene mantenuta la configurazione di Kubernetes. Mentre in GKE i componenti del control plane di Kubernetes sono gestiti e mantenuti da Google, in Google Distributed Cloud i componenti del control plane sono gestiti dagli amministratori locali.

In Google Distributed Cloud, i componenti del control plane vengono eseguiti all'interno della tua rete aziendale. Puoi proteggere il server API Kubernetes utilizzando le policy di rete e i firewall aziendali esistenti. Puoi anche assegnare un indirizzo IP interno al server API e limitare l'accesso all'indirizzo.

Tutte le comunicazioni in Google Distributed Cloud avvengono tramite canali TLS, che sono regolati da tre autorità di certificazione (CA): etcd, cluster e org:

  • La CA etcd protegge la comunicazione dal server API alle repliche etcd e il traffico tra le repliche etcd. Questa CA è autofirmata.
  • La CA del cluster protegge la comunicazione 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 agli utenti esterni. Sei tu a gestire questa CA.

Per i control plane di controllo amministratore, le chiavi vengono archiviate sul nodo del control plane. Per i cluster utente, le chiavi vengono archiviate come secret Kubernetes nel control plane di amministrazione. Il server API è configurato con un certificato fornito dall'utente e 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 quella firmata dalla CA dell'organizzazione.

L'autenticazione del cluster è gestita da certificati e token di connessione dei account di servizio. In qualità di amministratore, esegui l'autenticazione nel control plane 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 control plane e i nodi, i certificati vengono creati o ruotati a ogni upgrade.
  • Le CA possono essere ruotate raramente o on demand.

Sicurezza dei nodi

Google Distributed Cloud esegue il deployment dei workload in istanze VMware, che vengono collegate ai cluster come nodi. Le sezioni seguenti mostrano come utilizzare le funzionalità di sicurezza a livello di nodo disponibili.

Ubuntu

Google Distributed Cloud utilizza una versione ottimizzata di Ubuntu come sistema operativo su cui eseguire il control plane e i nodi Kubernetes. Ubuntu include un ricco insieme di funzionalità di sicurezza moderne e Google Distributed Cloud implementa diverse funzionalità di miglioramento della sicurezza per i cluster, tra cui:

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

Upgrade dei nodi

Dovresti eseguire regolarmente l'upgrade dei nodi. Di tanto in tanto, i problemi di sicurezza nel runtime del container, in Kubernetes stesso o nel sistema operativo del nodo potrebbero richiedere l'upgrade dei nodi con maggiore urgenza. Quando esegui l'upgrade del cluster, il software di ogni nodo viene aggiornato all'ultima versione.

Protezione dei workload

Kubernetes consente agli utenti di eseguire rapidamente il provisioning, la scalabilità e l'aggiornamento dei workload 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 dei processi dei container dei pod

Limitare i privilegi dei processi containerizzati è importante per la sicurezza complessiva del cluster. Kubernetes Engine ti consente di impostare opzioni relative alla sicurezza utilizzando il contesto di sicurezza sia sui pod che sui container. Queste impostazioni ti consentono di modificare le impostazioni di sicurezza dei tuoi processi, ad esempio:

  • Utente e gruppo da eseguire.
  • Funzionalità Linux disponibili.
  • Escalation dei privilegi.

Il sistema operativo predefinito dei nodi, Ubuntu, applica le policy di sicurezza AppArmor di Docker predefinite a tutti i container avviati da Kubernetes. Puoi visualizzare il template del profilo su GitHub. Tra le altre cose, il profilo nega ai container le seguenti funzionalità:

  • Scrittura di file direttamente in una directory dell'ID di processo (/proc/).
  • Scrittura su file non presenti 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 generare avvisi sugli eventi che si verificano negli ambienti Google Distributed Cloud. Gli amministratori possono utilizzare le informazioni registrate per eseguire analisi forensi, generare avvisi in tempo reale o catalogare come e da chi viene utilizzato un parco risorse di cluster Kubernetes Engine.

Per impostazione predefinita, Google Distributed Cloud registra l'attività di amministrazione. Facoltativamente, puoi anche registrare gli eventi di accesso ai dati, a seconda dei tipi di operazioni che ti interessa 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 dalla UI tramite Connect vengono registrate dal cluster.

Crittografia

Se i tuoi cluster e workload si connettono in modo sicuro ai serviziGoogle 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 tuoi servizi. Puoi generare, utilizzare, ruotare ed eliminare chiavi di crittografia AES256, RSA 2048, RSA 3072, RSA 4096, EC P256 ed EC P384. Cloud Key Management Service è integrato con Identity and Access Management (IAM) e Cloud Audit Logs per consentirti di gestire le autorizzazioni per le singole chiavi e monitorare il modo in cui vengono utilizzate. Utilizza Cloud Key Management Service per proteggere i secret e altri dati sensibili che devi archiviare. In caso contrario, puoi scegliere di utilizzare una delle seguenti alternative:

  • Secret Kubernetes
  • Hashicorp Vault
  • HSM di rete Thales Luna
  • Google Cloud Hardware Security Module (HSM)

Secret Kubernetes

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