Questa pagina descrive le funzionalità di sicurezza incluse in GKE su AWS, inclusi tutti i livelli della sua infrastruttura, e come configurare le funzionalità di sicurezza in base alle tue esigenze.
Panoramica
GKE su AWS offre diverse funzionalità per proteggere i tuoi workload, inclusi i contenuti dell'immagine container, il runtime del container, la rete del cluster e l'accesso al server API del cluster.
È preferibile 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 ai tuoi utenti e carichi di lavoro. Potresti dover scendere a compromessi per consentire il giusto livello di flessibilità e sicurezza.
Responsabilità condivise
Quando utilizzi GKE su AWS, accetti di assumerti determinate responsabilità per i tuoi cluster. Per maggiori informazioni, consulta Responsabilità condivise dei cluster GKE.
Autenticazione e autorizzazione
L'autenticazione a un cluster utente GKE su AWS avviene tramite uno dei seguenti metodi:
- Utilizzare lo strumento
anthos-gke
. - Utilizzo di un token del service account Kubernetes con la console.Google Cloud
- Utilizzo di OpenID Connect (OIDC).
Per configurare un accesso più granulare alle risorse Kubernetes a livello di cluster o all'interno degli spazi dei nomi Kubernetes, utilizza il controllcontrollo dell'accessosi basato sui ruoli (RBAC) di Kubernetes. RBAC ti consente di creare criteri dettagliati per definire a quali operazioni e risorse consenti l'accesso a utenti e service account. 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 AWS disattiva il controllo dell'accesso basato su attributi (ABAC) legacy.
Crittografia
Per impostazione predefinita, GKE su AWS cripta
i dati in etcd
at-rest, i volumi EBS, i secret Kubernetes e
i componenti del control plane con
AWS Key Management Service (KMS).
Per criptare i dati sensibili nei cluster utente, puoi utilizzare uno dei seguenti metodi:
- Secret Kubernetes
- Hashicorp Vault
Secret Kubernetes
Le risorse Secret di Kubernetes archiviano dati sensibili, come password, token OAuth e chiavi SSH, nei cluster. L'archiviazione di 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 la modalità di utilizzo dei dati sensibili e riduce il rischio di esporre i dati a utenti non autorizzati.
Hashicorp Vault
GKE su AWS può utilizzare Hashicorp Vault per proteggere i secret sui cluster utente. Per ulteriori informazioni, consulta la sezione Utilizzo di HashiCorp Vault su GKE su AWS.
Sicurezza del piano di controllo
I componenti del control plane includono il servizio di gestione e il server API Kubernetes, lo scheduler, i controller e il database etcd del cluster utente. In GKE su AWS, gli amministratori locali gestiscono i componenti del control plane.
In GKE su AWS, i componenti del control plane vengono eseguiti su AWS. Puoi proteggere il server API di GKE su AWS utilizzando i gruppi di sicurezza AWS e le ACL di rete.
Tutte le comunicazioni in GKE su AWS avvengono tramite canali Transport Layer Security (TLS) regolati dalle seguenti autorità di certificazione (CA):
- 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 utente protegge la comunicazione tra il server API e tutti i client API Kubernetes interni (kubelet, controller, scheduler). Questa CA è criptata con KMS.
- La CA del servizio di gestione è criptata con AWS KMS. Viene creato quando esegui
anthos-gke init
e archiviato nel workspace Terraform. Quando utilizziterraform apply
per creare il servizio di gestione, la chiave CA viene passata come dati utente di AWS EC2 e decriptata da AWS KMS all'avvio del cluster.
Per il servizio di gestione, le chiavi del control plane vengono archiviate sui [nodi]{:.external} del control plane. Per i cluster utente, le chiavi vengono archiviate come segreti Kubernetes nel control plane del servizio di gestione.
L'autenticazione del cluster in GKE su AWS viene gestita da certificati e token di autenticazione delaccount di serviziot. In qualità di amministratore, esegui l'autenticazione al control plane utilizzando il certificato amministrativo per il servizio di gestione (che utilizzi per la creazione iniziale del binding 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, GKE su AWS ruota i certificati TLS a ogni upgrade.
- Puoi anche ruotare manualmente le credenziali di sicurezza.
Sicurezza dei nodi
GKE su AWS esegue il deployment dei tuoi workload nei pool di nodi delle istanze AWS EC2. Le sezioni seguenti spiegano come utilizzare le funzionalità di sicurezza a livello di nodo in GKE su AWS.
Ubuntu
GKE su AWS utilizza una versione ottimizzata di Ubuntu come sistema operativo su cui eseguire il piano di controllo e i nodi Kubernetes. Ubuntu include un ricco insieme di funzionalità di sicurezza moderne e GKE su AWS implementa diverse funzionalità che migliorano la sicurezza dei cluster, tra cui:
- Set di pacchetti ottimizzati.
- Google Cloud-tailored Linux kernel.
- Account utente limitati e accesso root disabilitato.
Sono disponibili guide aggiuntive per la sicurezza per Ubuntu, ad esempio:
Upgrade dei nodi
Ti consigliamo di eseguire l'upgrade dei nodi regolarmente. 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 in modo più urgente. Quando esegui l'upgrade del cluster utente, il software di ogni nodo viene aggiornato alle versioni più recenti. Inoltre, l'upgrade dei nodi ruota le credenziali di crittografia.
Protezione dei carichi di lavoro
Kubernetes consente agli utenti di eseguire rapidamente il provisioning, lo scale e l'aggiornamento dei carichi di lavoro basati su container. Questa sezione descrive le tattiche che puoi utilizzare per limitare gli effetti collaterali dell'esecuzione di container sul cluster e sui servizi Google Cloud .
Limitare i privilegi dei processi dei container di pod
Limitare i privilegi dei processi in container è importante per la sicurezza del tuo cluster. Puoi impostare opzioni relative alla sicurezza con il contesto di sicurezza di pod e container. Queste impostazioni ti consentono di modificare le impostazioni di sicurezza dei tuoi processi, ad esempio:
- Utente e gruppo che eseguono il processo.
- Funzionalità Linux disponibili.
- Escalation dei privilegi.
Il sistema operativo del nodo GKE su AWS predefinito, 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 ai container le seguenti capacità:
- Scrittura nei file direttamente in una directory ID processo (
/proc/
). - Scrittura in file che non si trovano in
/proc/
. - Scrittura su file in
/proc/sys
diverso da/proc/sys/kernel/shm*
. - Montaggio dei file system.
Passaggi successivi
- Installa un servizio di gestione.
- Utilizza HashiCorp Vault su GKE su AWS.
- Ruota le credenziali di sicurezza.