In questa pagina vengono descritte le funzionalità di sicurezza incluse in GKE On-Prem, inclusi tutti i livelli della relativa infrastruttura, e la configurazione di queste funzionalità di sicurezza in base alle tue esigenze.
Panoramica
GKE On-Prem offre diverse funzionalità per aiutarti a proteggere i tuoi carichi di lavoro, inclusi i contenuti dell'immagine container, il runtime del container, la rete del 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 agli utenti e ai carichi di lavoro. Potrebbe essere necessario trovare dei compromessi per offrire il giusto livello di flessibilità e sicurezza.
Autenticazione e autorizzazione
Esegui l'autenticazione sui cluster on-prem di GKE utilizzando OpenID Connect
(OIDC) (tramite kubectl) o il token dell'account di servizio Kubernetes tramite la
Cloud Console.
Per configurare un accesso più granulare alle risorse Kubernetes a livello di cluster o all'interno degli spazi dei nomi di Kubernetes, utilizzi il controllo degli accessi basato sui ruoli (RBAC) di Kubernetes. RBAC consente di creare criteri dettagliati che definiscono le operazioni e le risorse a cui vuoi consentire agli utenti e agli account di servizio di accedere. 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, GKE On-Prem disabilita il Controllo degli accessi basato sugli attributi (ABAC) legacy.
Sicurezza del piano di controllo
I componenti del piano di controllo includono il server, lo scheduler, i controller e il database etcd di Kubernetes in cui la configurazione di Kubernetes viene mantenuto. 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-Prem.
In GKE On-Prem, i componenti del piano di controllo vengono eseguiti all'interno della tua rete aziendale. Puoi proteggere il server API GKE On-Prem utilizzando i tuoi criteri di rete aziendale e i firewall esistenti. Puoi anche assegnare un indirizzo IP privato al server API e limitare l'accesso a tale indirizzo.
Tutte le comunicazioni in GKE on-prem avvengono tramite canali TLS, gestiti 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 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 a utenti esterni. Gestisci questa CA.
Per i piani di controllo dell'amministratore, le chiavi sono archiviate nel nodo del piano di controllo. Per i cluster utente, le chiavi vengono archiviate come Kubernetes Secret nel piano di controllo dell'amministratore. Il server API è configurato con un certificato fornito dall'utente firmato dalla CA dell'organizzazione. Il server API utilizza il nome del server (SNI) per determinare se utilizzare la chiave firmata dalla CA del cluster o la chiave firmata dalla CA dell'organizzazione.
L'autenticazione del cluster in GKE On-Prem è gestita da certificati e token di connessione dell'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 seguenti modi:
- Per il server API, i piani di controllo e i nodi, i certificati vengono creati o ruotati a ogni upgrade.
- Le autorità di certificazione possono essere ruotate raramente o on demand.
Sicurezza dei nodi
GKE On-Prem esegue il deployment dei carichi di lavoro nelle istanze VMware, che sono collegate ai tuoi cluster come nodi. Le sezioni seguenti mostrano come utilizzare le funzionalità di sicurezza a livello di nodo disponibili in GKE On-Prem.
Ubuntu
GKE On-Prem 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 moderne funzionalità di sicurezza e GKE On-Prem implementa diverse funzionalità di miglioramento della sicurezza per i cluster, tra cui:
- Set di pacchetti ottimizzato.
- kernel Linux personalizzato per Google Cloud.
- Aggiornamenti automatici della sicurezza del sistema operativo.
- Account utente limitati e accesso root disattivato.
Sono disponibili guide per la sicurezza aggiuntive per Ubuntu, come:
Upgrade dei nodi
Dovresti eseguire l'upgrade di nodi su base regolare. Di tanto in tanto, i problemi di sicurezza nel runtime del container, in Kubernetes o nel sistema operativo dei nodi potrebbero richiedere l'upgrade 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 il provisioning, scalare e aggiornare rapidamente i 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 del cluster, gli host su cui vengono eseguiti e i servizi GCP abilitati nel loro progetto.
Limitazione dei privilegi di processo del container del pod
La limitazione dei privilegi dei processi containerizzati è importante per la sicurezza complessiva del cluster. Kubernetes Engine ti consente di impostare opzioni relative alla sicurezza tramite il contesto di sicurezza sia su pod che su container. Queste impostazioni consentono di modificare le impostazioni di sicurezza dei processi, ad esempio:
- Utente e gruppo da eseguire.
- Funzionalità di Linux disponibili.
- Riassegnazione dei privilegi.
Il sistema operativo nodo on-prem predefinito di GKE, Ubuntu, applica i criteri di sicurezza 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 funzionalità ai container:
- Scrittura in file direttamente in una directory di ID processo (/proc/).
- Scrivere in file che non sono in /proc/.
- Scrittura in file in /proc/sys diversi da /proc/sys/kernel/shm*.
- Montaggio di 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-Prem. Gli amministratori possono utilizzare le informazioni registrate per eseguire analisi forense, avvisi in tempo reale o catalogare l'utilizzo e l'accesso di un parco di cluster Kubernetes Engine.
Per impostazione predefinita, l'attività di amministrazione dei log on-prem di GKE. Se vuoi, puoi anche registrare gli eventi di accesso ai dati, a seconda dei tipi di operazioni che vuoi esaminare.
L'agente Connect comunica solo con il server API locale in esecuzione on-premise e ogni cluster deve avere un proprio set di audit log. Tutte le azioni eseguite dagli utenti dalla UI tramite Connect vengono registrate da quel cluster.
Crittografia
Google Cloud Key Management Service (Cloud KMS) è un servizio di gestione delle chiavi 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 Cloud IAM e Cloud Audit Logging in modo da poter gestire le autorizzazioni per le singole chiavi e monitorarne l'utilizzo. Utilizza Cloud KMS per proteggere secret e altri dati sensibili che devi archiviare.
Se i tuoi cluster e carichi di lavoro GKE On-Prem si connettono in modo sicuro ai servizi Google Cloud tramite Cloud VPN, puoi utilizzare Cloud KMS per la gestione delle chiavi. In alternativa, puoi scegliere una delle seguenti alternative:
- Secret di Kubernetes
- Hashicorp Vault
- HSM (Hardware Security Module)
Secret di Kubernetes
Le risorse Secret di Kubernetes archiviano i dati sensibili, come password, token OAuth e chiavi SSH, nei cluster. L'archiviazione di dati sensibili nei secret è più sicura dell'archiviazione in ConfigMap in testo non crittografato o nelle specifiche dei pod. L'uso dei secret ti consente di controllare in che modo vengono utilizzati i dati sensibili e riduce il rischio di esporre i dati a utenti non autorizzati.