Con la velocità di sviluppo in Kubernetes, spesso puoi usare nuove funzionalità di sicurezza. Questa pagina illustra come implementare la nostra attuale guida per la protezione dei cluster GKE On-Prem.
Questa guida dà la priorità alle mitigazioni di alto valore della sicurezza che richiedono un intervento da parte tua al momento della creazione del cluster. Di seguito sono elencate le funzionalità meno critiche, le impostazioni protette da impostazione predefinita e quelle che possono essere abilitate dopo la creazione del cluster. Per una panoramica generale degli argomenti relativi alla sicurezza, consulta Sicurezza.
Crittografia delle VM vSphere
I nodi cluster GKE On-Prem vengono eseguiti su macchine virtuali (VM) nel tuo cluster vSphere. Segui le indicazioni sulla sicurezza di VMware vSphere e le best practice per la crittografia delle VM.
Aggiorna la tua infrastruttura in modo tempestivo
Kubernetes introduce spesso nuove funzionalità di sicurezza e fornisce patch di sicurezza. Per informazioni sulle patch di sicurezza, consulta i bollettini sulla sicurezza di GKE On-Prem.
Sei responsabile di mantenere aggiornati i cluster GKE On-Prem. Per ogni release, consulta le note di rilascio Pianifica l'aggiornamento alle nuove release della patch ogni tre mesi e alle versioni secondarie ogni tre mesi. Scopri come eseguire l'upgrade dei cluster.
Sei inoltre responsabile dell'upgrade e della protezione dell'infrastruttura vSphere:
- Definisci una procedura per attuare patch e upgrade tempestivi delle tue macchine virtuali.
- Tieniti al corrente sugli ultimi avvisi relativi alla sicurezza delle VMware
- Segui le istruzioni su come applicare le patch agli host
Configura OpenID Connect
Se vuoi configurare l'autenticazione utente per i cluster, utilizza OpenID Connect (OIDC).
Quando concedi l'accesso tramite il controllo dell'accesso basato sui ruoli (RBAC), devi anche utilizzare i gruppi OIDC. In questo modo, non sarà necessario aggiornare manualmente la configurazione RBAC quando gli utenti cambiano ruolo.
Utilizza il principio del privilegio minimo per gli account di servizio Google Cloud
GKE On-Prem richiede quattro account di servizio Google Cloud:
- Un account di servizio autorizzato per accedere al software GKE On-Prem. Lo crei quando acquisti Anthos.
- Un account di servizio di registrazione che deve essere utilizzato da Connect per registrare i cluster GKE On-Prem con Google Cloud.
- Un account di servizio Connect che deve essere utilizzato da Connect per stabilire una connessione tra i cluster GKE On-Prem e Google Cloud.
- Un account di servizio Cloud Logging per la raccolta dei log del cluster, che deve essere utilizzato da Cloud Logging.
Durante l'installazione, associ i ruoli Identity and Access Management a questi account di servizio. Questi ruoli concedono agli account di servizio privilegi specifici all'interno del progetto. Per configurare questi account di servizio devi utilizzare il principio di privilegio minimo: concedere solo i privilegi necessari per eseguire il ruolo degli account di servizio.
Utilizzare gli spazi dei nomi di Kubernetes e RBAC per limitare l'accesso
Per fornire ai team l'accesso con privilegi minimi a Kubernetes, crea spazi dei nomi o cluster specifici dell'ambiente di Kubernetes. Assegna i centri di costo e le etichette appropriate a ciascuno spazio dei nomi per la responsabilità e lo storno di addebito. Offri agli sviluppatori solo il livello di accesso ai loro spazi dei nomi di cui hanno bisogno per eseguire il deployment e gestire le applicazioni, in particolare in produzione.
Delinea le attività che i tuoi utenti devono intraprendere nel cluster e definisci le autorizzazioni necessarie per completare ogni attività. Per concedere le autorizzazioni a livello di cluster e spazio dei nomi, utilizza KubernetesRBAC.
Oltre alle autorizzazioni per gli account di servizio Google Cloud utilizzati per installare GKE On-Prem, IAM non si applica ai cluster GKE On-Prem.
Limita le autorizzazioni RBAC del rilevamento cluster
Per impostazione predefinita, Kubernetes avvia i cluster con un set permissivo di ClusterRoleBindings di rilevamento, che consente un accesso esteso alle informazioni sulle API del cluster, incluse quelle delle CustomResourceDefinitions (CRD). Queste autorizzazioni sono ridotte in Kubernetes 1.14, che sarà disponibile a partire dalla versione 1.2 di GKE On-Prem. Se è necessario limitare l'accesso, valuta la possibilità di configurare il firewall on-prem in modo appropriato.
Gestione di secret
Per fornire un ulteriore livello di protezione per i dati sensibili, come i secret di Kubernetes archiviati in etcd, configura un gestore di secret integrato con i cluster GKE On-Prem.
Se esegui carichi di lavoro in più ambienti, potresti preferire una soluzione che funzioni sia per Google Kubernetes Engine sia per GKE On-Prem. Se scegli di utilizzare un gestore secret esterno, ad esempio HashiCorp Vault, devi configurarlo prima di creare i cluster GKE On-Prem.
Sono disponibili diverse opzioni per la gestione dei secret.
- Puoi utilizzare i secret di Kubernetes in modo nativo in GKE On-Prem. Ci aspettiamo che i cluster utilizzino la crittografia vSphere per le VM come descritto in precedenza, che fornisce la protezione di base della crittografia a riposo per i secret. I secret non sono ulteriormente criptati per impostazione predefinita. Per criptare questi secret a livello di applicazione, puoi modificare il EncryptionConfig e utilizzare un plug-in di gestione delle chiavi.
- Puoi utilizzare un Secretster Manager esterno, ad esempio HashiCorp Vault. Puoi autenticarti su HashiCorp utilizzando un account di servizio Kubernetes o un account di servizio Google Cloud.
Limita l'accesso di rete al piano di controllo e ai nodi
Dovresti limitare l'esposizione del piano di controllo e dei nodi del cluster a Internet. Queste scelte non possono essere modificate dopo la creazione del cluster.
Per impostazione predefinita, i nodi cluster GKE On-Prem vengono creati utilizzando indirizzi RFC 1918 e questo comportamento non deve essere modificato. Devi implementare le regole del firewall sulla tua rete on-prem per limitare l'accesso al piano di controllo.
Utilizza i criteri di rete per limitare il traffico tra i pod
Per impostazione predefinita, tutti i servizi in un cluster GKE On-Prem possono comunicare tra loro. Dovresti controllare la comunicazione da servizio a servizio secondo necessità per i tuoi carichi di lavoro.
Limitare l'accesso di rete ai servizi rende molto più difficile il trasferimento laterale degli attacchi all'interno del cluster e offre inoltre una protezione più efficace contro i denial of service accidentali o deliberati. Ecco due modi consigliati per controllare il traffico:
- Per controllare il traffico L7 verso gli endpoint di applicazione, utilizza Istio. Scegli questa opzione se ti interessa bilanciamento del carico, autorizzazione del servizio, limitazione, quota e metriche.
- Per controllare il traffico L4 tra i pod, utilizza i criteri di rete di Kubernetes. Scegli questa opzione se stai cercando la funzionalità di controllo di accesso di base esposta da Kubernetes.
Puoi abilitare i criteri di rete di Istio e Kubernetes dopo aver creato i cluster GKE On-Prem. Se necessario, puoi utilizzarli insieme.
Utilizza il controller dei criteri Anthos Config Management
I controller di ammissione di Kubernetes sono plug-in che regolano e applicano l'utilizzo di un cluster Kubernetes. Devi abilitare i controller di ammissione per utilizzare le funzionalità di sicurezza avanzate di Kubernetes. I controller di ammissione sono una parte importante dell'approccio per la difesa in profondità nella protezione del cluster.
La best practice prevede l'utilizzo di controller delle norme di Anthos Config Management. Policy Controller utilizza il Framework vincolo dell'OPA per descrivere e applicare il criterio come CRD. I vincoli che vuoi applicare al cluster sono definiti nei modelli di vincolo, che vengono implementati nei cluster.
Monitorare la configurazione del cluster
Dovresti controllare le configurazioni del cluster per individuare eventuali deviazioni dalle impostazioni definite. Per controllare automaticamente queste configurazioni, dovresti utilizzare una soluzione che funzioni con i tuoi cluster GKE On-Prem, indipendentemente da dove ne sia stato eseguito il deployment. Consulta la pagina Partner Anthos.
Lascia i metodi di autenticazione del client legacy disattivati (opzione predefinita)
Esistono diversi metodi di autenticazione al server API Kubernetes. OIDC è il meccanismo di autenticazione consigliato. L'autenticazione di base è disabilitata per impostazione predefinita. Non utilizzare il certificato x509 per l'autenticazione.
Lascia abilitato Cloud Logging (impostazione predefinita)
Per ridurre l'overhead operativo e per mantenere una visualizzazione consolidata dei tuoi log, implementa una strategia di logging coerente in tutti i deployment del cluster. GKE On-Prem è integrato con la suite operativa di Google Cloud per impostazione predefinita. Devi abilitare la suite operativa di Google Cloud durante l'installazione
completando la specifica stackdriver nel
file di configurazione GKE On-Prem.
Per tutti i cluster GKE On-Prem è abilitato l'audit logging di Kubernetes per impostazione predefinita. L'audit logging conserva un record cronologico delle chiamate effettuate al server API Kubernetes. Le voci dei log di controllo sono utili per esaminare le richieste API sospette, raccogliere statistiche e monitorare gli avvisi relativi alle chiamate API indesiderate.
I cluster GKE On-Prem integrano gli audit logging di Kubernetes con gli audit log di Google Cloud e Cloud Logging. GKE On-Prem può anche instradare da Logging al tuo sistema di logging.
La suite operativa di Google Cloud raccoglie e aggrega i log dai tuoi cluster. Se attivi la suite operativa di Google Cloud, puoi ricevere assistenza migliore da Google. Per ulteriori informazioni, consulta la sezione Logging e monitoraggio.
Lascia disabilitato Kubernetes Dashboard (valore predefinito)
La dashboard di Kubernetes è supportata da un account di servizio Kubernetes con privilegi molto elevati ed è stata utilizzata in diversi attacchi di alto profilo a Kubernetes. Google Cloud Console è l'interfaccia web consigliata per GKE On-Prem. Offre molte delle stesse funzionalità di Chrome, supporta IAM e RBAC per Kubernetes senza privilegi elevati e fornisce funzionalità di Anthos come la gestione multi-cluster.
La dashboard Kubernetes non è inclusa in GKE On-Prem.
Lascia disattivato il controllo dell'accesso basato su attributi (impostazione predefinita)
In Kubernetes, utilizzi RBAC per concedere autorizzazioni alle risorse a livello di cluster e spazio dei nomi. RBAC consente di definire ruoli con regole contenenti un set di autorizzazioni.
Per impostazione predefinita, il controllo dell'accesso basato su attributi (ABAC) è disabilitato sui cluster GKE On-Prem e non è necessario abilitarlo.