Rafforza la sicurezza del cluster

Questo documento fornisce le best practice per migliorare la sicurezza dei tuoi ambienti Google Kubernetes Engine (GKE). Gli esperti di sicurezza che definiscono, gestiscono e implementano policy e procedure possono utilizzare queste best practice per proteggere i dati della loro organizzazione.

Dovresti già avere familiarità con quanto segue:

I nuovi cluster GKE implementano per impostazione predefinita molte delle best practice descritte in questo documento. I cluster in modalità Autopilot hanno una security posture predefinita più rigorosa rispetto ai cluster in modalità Standard.

Per implementare e applicare le best practice descritte in questo documento in tutta l'organizzazione, prendi in considerazione i seguenti servizi:

  • Security Command Center: controlla automaticamente se i tuoi cluster implementano molte di queste best practice e verifica la presenza di altre configurazioni errate comuni.
  • Servizio criteri dell'organizzazione: applica best practice specifiche alla risorsa GKE in un'organizzazione, una cartella o un progetto. Sezioni specifiche di questo documento contengono link alla console Google Cloud per applicare vincoli gestiti per questi suggerimenti.

Google Cloud environment design

Le sezioni seguenti descrivono le misure di sicurezza da prendere in considerazione quando pianifichi e progetti le risorse in Google Cloud. Gli architetti cloud devono utilizzare questi suggerimenti durante la pianificazione e la definizione Google Cloud dell'architettura.

Best practice

Pianificare la struttura delle risorse Google Cloud

Consigliato: implementa il progetto di fondazione di un'azienda, che è una base completa per il tuo ambiente aziendale basata sulle nostre best practice.

L'architettura delle tue organizzazioni, delle tue cartelle e dei tuoi progetti influisce sulla tua postura di sicurezza. Google Cloud Progetta queste risorse di base in modo da consentire controlli di governance e sicurezza su larga scala nei tuoi servizi.

Pianificare ambienti multi-tenant

Consigliato: implementa Google Cloud e le best practice di GKE per le piattaforme aziendali multi-tenant.

Molti clienti GKE gestiscono team distribuiti, con flussi di lavoro e responsabilità di ingegneria separati. Questi ambienti multi-tenant devono avere un'infrastruttura condivisa che tutti gli sviluppatori possono utilizzare, limitando l'accesso ai componenti in base a ruoli e responsabilità. Il progetto base per le applicazioni aziendali si basa sul progetto base per le piattaforme aziendali per aiutarti a eseguire il deployment di piattaforme per sviluppatori interne in ambienti multi-tenant.

Per saperne di più, consulta i seguenti documenti:

Utilizzare i tag per raggruppare le risorse Google Cloud

Consigliato: utilizza i tag per organizzare le risorse GKE per l'applicazione condizionale delle policy e una migliore responsabilità tra i team.

I tag sono metadati che puoi allegare alle risorse nelle tue organizzazioni, cartelle e progetti per identificare le dimensioni aziendali nella gerarchia delle risorseGoogle Cloud . Puoi collegare tag ai cluster e ai pool di nodi GKE e poi utilizzarli per applicare in modo condizionale criteri dell'organizzazione, criteri IAM o criteri firewall.

Per saperne di più, consulta i seguenti documenti:

Pianifica le reti VPC

Consigliato: implementa Google Cloud e le best practice di GKE per la progettazione della rete VPC.

La progettazione della rete VPC e le funzionalità che utilizzi influiscono sulla sicurezza della rete. Pianifica le tue reti in base alla gerarchia delle risorse e ai tuoi obiettivi di sicurezza. Google CloudPer saperne di più, consulta i seguenti documenti:

Progettare un piano di risposta agli incidenti

Consigliato: crea e gestisci un piano di risposta agli incidenti che soddisfi i tuoi obiettivi di sicurezza e affidabilità.

Gli incidenti di sicurezza possono verificarsi anche quando implementi ogni possibile controllo di sicurezza. Un piano di risposta agli incidenti ti aiuta a identificare potenziali lacune nei tuoi controlli di sicurezza, a rispondere in modo rapido ed efficace a vari tipi di incidenti e a ridurre i tempi di inattività durante un'interruzione. Per saperne di più, consulta i seguenti documenti:

Google Cloud sicurezza di rete

Le sezioni seguenti forniscono consigli per la sicurezza delle tue reti VPC. Gli architetti di rete e gli amministratori di rete devono applicare questi consigli per ridurre la superficie di attacco a livello di rete e per limitare l'impatto dell'accesso alla rete non intenzionale.

Best practice

Utilizza regole firewall con privilegi minimi

Consigliato: quando crei regole firewall, utilizza il principio del privilegio minimo per fornire l'accesso solo per lo scopo richiesto. Assicurati che le regole firewall non siano in conflitto con le regole firewall predefinite di GKE o non le sostituiscano, se possibile.

GKE crea regole firewall VPC predefinite per abilitare la funzionalità del sistema e applicare buone pratiche di sicurezza. Se crei regole firewall permissive con una priorità superiore a una regola firewall predefinita (ad esempio, una regola firewall che consente tutto il traffico in entrata per il debug), il tuo cluster è a rischio di accesso non intenzionale.

Utilizzare VPC condiviso per il traffico tra progetti

Consigliato: utilizza il VPC condiviso per consentire alle risorse di più progetti di comunicare tra loro utilizzando indirizzi IP interni.

Le risorse in progetti diversi della tua organizzazione potrebbero dover comunicare tra loro. Ad esempio, i servizi frontend in un cluster GKE in un progetto potrebbero dover comunicare con le istanze Compute Engine di backend in un progetto diverso.

Per saperne di più, consulta i seguenti documenti:

Utilizza reti separate per isolare gli ambienti

Consigliato: utilizza reti VPC condiviso separate per gli ambienti di staging, test e produzione.

Isola gli ambienti di sviluppo l'uno dall'altro per ridurre l'impatto e il rischio di accesso non autorizzato o di bug distruttivi. Per saperne di più, vedi Più progetti host.

Impostazioni di sicurezza immutabili

Le sezioni seguenti forniscono consigli per la sicurezza che puoi configurare solo quando crei cluster o pool di nodi. Non puoi aggiornare i cluster o i node pool esistenti per modificare queste impostazioni. Gli amministratori della piattaforma devono applicare questi consigli ai nuovi cluster e node pool.

Utilizza i service account del nodo IAM con privilegi minimi

Consigliato: utilizza un account di servizio IAM personalizzato per i tuoi cluster GKE e i tuoi node pool anziché utilizzare il account di servizio Compute Engine predefinito.

GKE utilizza i service account IAM collegati ai nodi per eseguire attività di sistema come il logging e il monitoraggio. Come minimo, questi service account nodo devono avere il ruolo Kubernetes Engine Default Node Service Account (roles/container.defaultNodeServiceAccount) sul tuo progetto. Per impostazione predefinita, GKE utilizza l'account di servizio predefinito di Compute Engine, che viene creato automaticamente nel tuo progetto, come service account del nodo.

Se utilizzi il account di servizio predefinito di Compute Engine per altre funzioni nel tuo progetto o nella tua organizzazione, il account di servizio potrebbe disporre di più autorizzazioni di quelle necessarie a GKE, il che potrebbe esporti a rischi per la sicurezza.

Il account di servizio collegato ai tuoi nodi deve essere utilizzato solo dai carichi di lavoro di sistema che eseguono attività come il logging e il monitoraggio. Per i tuoi carichi di lavoro, esegui il provisioning delle identità utilizzando Workload Identity Federation for GKE.

Per applicare questo consiglio nella tua organizzazione, utilizza il constraints/container.managed.disallowDefaultComputeServiceAccount vincolo della policy dell'organizzazione gestita. Per esaminare questo vincolo gestito nella console Google Cloud , vai alla pagina Dettagli policy.

Vai ai dettagli della policy

Utilizza un'immagine del nodo Container-Optimized OS

Consigliato: a meno che tu non abbia un requisito specifico per utilizzare Ubuntu o Windows, utilizza l'immagine del nodo Container-Optimized OS per i tuoi nodi.

Container-Optimized OS è creato, ottimizzato e protetto appositamente per l'esecuzione di container. Container-Optimized OS è l'unica immagine del nodo supportata per la modalità Autopilot ed è l'immagine del nodo predefinita per la modalità Standard.

Per saperne di più, consulta i seguenti documenti:

Configurazione della sicurezza dei nodi

Le sezioni seguenti forniscono consigli per la sicurezza per la configurazione dei nodi GKE. Gli amministratori della piattaforma e gli esperti di sicurezza devono applicare questi suggerimenti per migliorare l'integrità dei nodi GKE.

Best practice

Utilizzare i nodi GKE schermati

Consigliato: abilita Shielded GKE Nodes, l'avvio protetto e il monitoraggio dell'integrità in tutti i cluster e i pool di nodi.

Shielded GKE Nodes fornisce controlli di identità e integrità verificabili che migliorano la sicurezza dei tuoi nodi. Shielded GKE Nodes e funzionalità come il monitoraggio dell'integrità dei nodi e l'avvio protetto sono sempre abilitati nei cluster Autopilot. Nei cluster standard:

  • Non disabilitare Shielded GKE Nodes nei cluster.
  • Abilita l'avvio protetto in tutti i tuoi node pool.
  • Non disattivare il monitoraggio dell'integrità nei tuoi node pool.

Per saperne di più su come attivare queste funzionalità, consulta Utilizzare Shielded GKE Nodes.

Per applicare questo consiglio nella tua organizzazione, utilizza il constraints/container.managed.enableShieldedNodes vincolo della policy dell'organizzazione gestita. Per esaminare questo vincolo gestito nella console Google Cloud , vai alla pagina Dettagli policy.

Vai ai dettagli della policy

Disabilita la porta di sola lettura di Kubelet non sicura

Consigliato: disattiva la porta di sola lettura kubelet e passa tutti i carichi di lavoro che utilizzano la porta 10255 alla porta più sicura 10250.

Il processo kubelet in esecuzione sui nodi gestisce un'API di sola lettura utilizzando la porta non sicura 10255. Kubernetes non esegue controlli di autenticazione o autorizzazione su questa porta. kubelet serve gli stessi endpoint sulla porta autenticata e più sicura 10250.

Per maggiori informazioni, consulta Disattiva la porta di sola lettura kubelet nei cluster GKE.

Per applicare questo consiglio nella tua organizzazione, utilizza il constraints/container.managed.disableInsecureKubeletReadOnlyPort vincolo della policy dell'organizzazione gestita. Per esaminare questo vincolo gestito nella console Google Cloud , vai alla pagina Dettagli policy.

Vai ai dettagli della policy

Controllo degli accessi

Le sezioni seguenti forniscono consigli per limitare l'accesso non autorizzato nel cluster. Gli ingegneri della sicurezza e gli amministratori di identità e account devono applicare questi consigli per ridurre la superficie di attacco e limitare l'impatto dell'accesso non autorizzato.

Best practice

Limita l'accesso al rilevamento delle API del cluster

Consigliato: limita l'accesso al control plane e ai nodi da internet per impedire l'accesso non intenzionale agli endpoint di rilevamento delle API del cluster.

Per impostazione predefinita, Kubernetes crea cluster con un insieme permissivo di ruoli di rilevamento API predefiniti. Questi ruoli predefiniti forniscono un ampio accesso alle informazioni sulle API di un cluster a vari gruppi predefiniti, ad esempio system:authenticated. Questi ruoli predefiniti non rappresentano un livello di sicurezza significativo per i cluster GKE. Ad esempio, il gruppo system:authenticated, che può leggere informazioni sulle API come CustomResources, viene assegnato a qualsiasi utente autenticato (incluso chiunque abbia un Account Google).

Per limitare l'accesso alle API di rilevamento del cluster:

  • Limita l'accesso al control plane: utilizza solo l'endpoint basato su DNS per l'accesso al control plane. Se utilizzi endpoint basati su IP, limita l'accesso a un insieme di intervalli di indirizzi noti configurando le reti autorizzate.
  • Configura nodi privati: disabilita gli indirizzi IP esterni dei nodi, in modo che i client esterni alla tua rete non possano accedere ai nodi.

Per saperne di più, consulta la sezione Informazioni sull'isolamento di rete.

Se non abiliti queste funzionalità di isolamento della rete, considera tutte le informazioni di rilevamento delle API (in particolare lo schema di CustomResources, le definizioni di APIService e le informazioni di rilevamento ospitate dai server API di estensione) come divulgate pubblicamente.

Posizionare i team e gli ambienti in spazi dei nomi o cluster separati

Concedi ai team l'accesso minimo a Kubernetes creando spazi dei nomi o cluster separati per ogni team e ambiente. Per ogni spazio dei nomi o cluster, assegna centri di costo ed etichette per responsabilità e riaddebito.

Puoi utilizzare le autorizzazioni IAM e RBAC insieme agli spazi dei nomi per limitare le interazioni degli utenti con le risorse del cluster nella console Google Cloud . Per maggiori informazioni, consulta Attivare l'accesso e visualizzare le risorse del cluster per spazio dei nomi.

Utilizzare il principio del privilegio minimo nelle norme di accesso

Consigliato: concedi agli sviluppatori solo l'accesso necessario per il deployment e la gestione delle applicazioni nel loro spazio dei nomi, soprattutto negli ambienti di produzione. Quando progetti le tue policy di controllo dell'accesso#39;accesso, mappa le attività che i tuoi utenti devono svolgere nel cluster e concedi loro solo le autorizzazioni che consentono di svolgere queste attività.

In GKE, puoi utilizzare IAM e controllo dell'accesso basato sui ruoli (RBAC) di Kubernetes per concedere autorizzazioni sulle risorse. Questi meccanismi di controllo dell'accesso funzionano insieme. Per ridurre la complessità della gestione dell'accesso, procedi nel seguente modo:

  • Per concedere l'accesso al tuo progetto o alle Google Cloud risorse, utilizza i ruoli IAM.

  • Per concedere l'accesso alle risorse Kubernetes nel cluster, ad esempio agli spazi dei nomi, utilizza RBAC.

Per ulteriori informazioni sulla pianificazione e la progettazione di policy IAM e RBAC, consulta i seguenti documenti:

Utilizza Workload Identity Federation for GKE per accedere alle Google Cloud API

Consigliato: per accedere alle risorse Google Cloud dai carichi di lavoro GKE, utilizza Workload Identity Federation for GKE.

Workload Identity Federation for GKE è il modo consigliato per autenticarsi nelle APIGoogle Cloud . Puoi concedere ruoli IAM su varie risorse alle entità nel tuo cluster, ad esempio ServiceAccount o pod Kubernetes specifici. Workload Identity Federation for GKE protegge anche i metadati sensibili sui nodi e fornisce un flusso di lavoro di autenticazione più sicuro rispetto ad alternative come i file di token statici.

Workload Identity Federation for GKE è sempre abilitato nei cluster Autopilot. Nei cluster Standard, abilita la federazione delle identità per i carichi di lavoro per GKE per tutti i cluster e i node pool. Inoltre, segui questi consigli:

  • Se utilizzi le librerie client Google Cloud nel codice dell'applicazione, non distribuire le credenziali Google Cloud ai tuoi carichi di lavoro. Il codice che utilizza le librerie client recupera automaticamente le credenziali per Workload Identity Federation for GKE.
  • Utilizza uno spazio dei nomi e un service account separati per ogni workload che necessita di un'identità distinta. Concedi le autorizzazioni IAM a service account specifici.

Per saperne di più, consulta Esegui l'autenticazione nelle API Google Cloud dai workload GKE.

Per applicare questo consiglio nella tua organizzazione, utilizza il constraints/container.managed.enableWorkloadIdentityFederation vincolo della policy dell'organizzazione gestita. Per esaminare questo vincolo gestito nella console Google Cloud , vai alla pagina Dettagli policy.

Vai ai dettagli della policy

Utilizzare i gruppi per gestire l'accesso

Consigliato: nelle tue norme di accesso, concedi le autorizzazioni a gruppi di utenti anziché a singoli utenti.

Quando gestisci gli utenti nei gruppi, il tuo sistema di gestione delle identità e gli amministratori delle identità possono controllare centralmente le identità modificando l'appartenenza degli utenti a vari gruppi. Questo tipo di gestione elimina la necessità di aggiornare i criteri RBAC o IAM ogni volta che un utente specifico ha bisogno di autorizzazioni aggiornate.

Puoi specificare Google Gruppi nei criteri IAM o RBAC. Per saperne di più, consulta i seguenti documenti:

Per applicare questo consiglio nella tua organizzazione, utilizza il constraints/container.managed.enableGoogleGroupsRBAC vincolo della policy dell'organizzazione gestita. Per esaminare questo vincolo gestito nella console Google Cloud , vai alla pagina Dettagli policy.

Vai ai dettagli della policy

Limitare l'accesso anonimo agli endpoint del cluster

Consigliato: impedisci le richieste anonime a tutti gli endpoint del cluster, ad eccezione degli endpoint di controllo di integrità dell'integrità, in tutti i cluster Autopilot e Standard.

Per impostazione predefinita, Kubernetes assegna l'utente system:anonymous e il gruppo system:unauthenticated alle richieste anonime agli endpoint del cluster. Se i criteri RBAC concedono a questo utente o gruppo ulteriori autorizzazioni, un utente anonimo potrebbe essere in grado di compromettere la sicurezza di un servizio o del cluster stesso.

Nelle versioni di GKE 1.32.2-gke.1234000 e successive, puoi limitare l'insieme di endpoint che le richieste anonime possono raggiungere solo agli endpoint di controllo di integrità dell'integrità del server API Kubernetes /healthz, /livez e /readyz. L'accesso anonimo a questi endpoint di controllo di integrità è necessario per verificare che un cluster funzioni correttamente.

Per limitare l'accesso anonimo agli endpoint del cluster, specifica LIMITED per il flag --anonymous-authentication-config quando utilizzi gcloud CLI o l'API GKE per creare o aggiornare i cluster Standard e Autopilot. GKE rifiuta le richieste anonime agli endpoint del cluster che non sono gli endpoint di controllo di integrità durante l'autenticazione. Le richieste anonime non raggiungono gli endpoint, anche se i criteri RBAC concedono l'accesso a utenti e gruppi anonimi. Le richieste rifiutate restituiscono uno stato HTTP 401.

Per applicare questo consiglio nella tua organizzazione, cartella o progetto utilizzando un criterio dell'organizzazione, crea un vincolo personalizzato con la condizione resource.anonymousAuthenticationConfig.mode. Per saperne di più e per un esempio di vincolo, consulta Limitare le azioni sulle risorse GKE utilizzando policy dell'organizzazione personalizzate.

Non fare affidamento solo su questa funzionalità per proteggere il tuo cluster. Implementa misure di sicurezza aggiuntive come le seguenti:

Sicurezza di rete GKE

Le sezioni seguenti forniscono consigli per migliorare la sicurezza di rete nei cluster. Gli amministratori di rete e gli esperti di sicurezza devono applicare questi consigli per proteggere i carichi di lavoro e l'infrastruttura da accessi esterni o interni non intenzionali.

Best practice

Limitare l'accesso al control plane

Consigliato: abilita l'endpoint basato su DNS per l'accesso al control plane e disabilita tutti gli endpoint del control plane basati su IP.

Per impostazione predefinita, le entità esterne, come i client su internet, possono raggiungere il tuo control plane. Puoi limitare l'accesso al control plane configurando l'isolamento di rete.

Per isolare il control plane, esegui una delle seguenti operazioni:

  • Utilizza solo l'endpoint basato su DNS (consigliato): abilita l'endpoint basato su DNS per il control plane e disabilita gli endpoint interni ed esterni basati su IP. Tutto l'accesso al control plane deve utilizzare l'endpoint basato su DNS. Puoi utilizzare i Controlli di servizio VPC per controllare chi può accedere all'endpoint basato su DNS.

    Per applicare questo consiglio nella tua organizzazione, utilizza il constraints/container.managed.enableControlPlaneDNSOnlyAccess vincolo della policy dell'organizzazione gestita. Per esaminare questo vincolo gestito nella console Google Cloud , vai alla pagina Dettagli policy.

    Vai ai dettagli della policy

  • Disattiva l'endpoint basato su IP esterno: rimuovi l'indirizzo IP esterno del control plane. I client esterni alla tua rete VPC non possono utilizzare l'indirizzo IP esterno per accedere al control plane.

    Questa opzione funziona bene se utilizzi tecnologie come Cloud Interconnect e Cloud VPN per connettere la rete aziendale alla rete VPC.

  • Utilizza le reti autorizzate con l'endpoint basato su IP esterno: limita l'accesso all'endpoint basato su IP esterno solo a un intervallo attendibile di indirizzi IP di origine.

    Questa opzione è ideale se non disponi di un'infrastruttura VPN esistente o se hai utenti remoti o filiali che accedono ai tuoi cluster utilizzando la rete internet pubblica.

Nella maggior parte degli scenari, utilizza solo l'endpoint basato su DNS per l'accesso al control plane. Se devi abilitare l'endpoint basato su IP, utilizza le reti autorizzate per limitare l'accesso al control plane alle seguenti entità:

  • Gli intervalli di indirizzi IP specificati.
  • Nodi GKE nella stessa rete VPC del cluster.
  • Indirizzi IP riservati a Google per la gestione del cluster.

Isolare i nodi da internet

Per impostazione predefinita, tutti i nodi GKE hanno un indirizzo IP esterno raggiungibile dai client su internet. Per rimuovere questo indirizzo IP esterno, attiva i nodi privati.

Per applicare questo consiglio nella tua organizzazione, utilizza il constraints/container.managed.enablePrivateNodes vincolo della policy dell'organizzazione gestita. Per esaminare questo vincolo gestito nella console Google Cloud , vai alla pagina Dettagli policy.

Vai ai dettagli della policy

Limitare il traffico di rete tra i pod

Consigliato: controlla il traffico di rete pod-to-pod utilizzando NetworkPolicies, un mesh di servizi o entrambi.

Per impostazione predefinita, ogni pod nel cluster può comunicare con tutti gli altri pod. Limitare l'accesso di rete tra i servizi rende molto più difficile per gli aggressori spostarsi lateralmente nel cluster. I tuoi servizi ottengono anche una certa protezione contro incidenti di tipo Denial of Service accidentali o intenzionali. A seconda dei tuoi requisiti, utilizza uno o entrambi i seguenti metodi per limitare il traffico da pod a pod:

Protezione dei dati sensibili

Le sezioni seguenti forniscono consigli per criptare i dati e proteggere le informazioni sensibili come le credenziali. Gli ingegneri della sicurezza e gli amministratori della piattaforma devono applicare questi consigli per ridurre il rischio di accesso non intenzionale ai dati critici.

Best practice

Criptare i dati del workload in uso

Utilizza la crittografia della memoria basata su hardware per proteggere i dati in uso nei tuoi workload utilizzando Confidential GKE Node. Puoi scegliere una tecnologia Confidential Computing in base ai tuoi requisiti. Per ulteriori informazioni, consulta Crittografia dei dati dei workload in uso con Confidential GKE Node.

Archivia i secret al di fuori del cluster

Consigliato: utilizza un gestore dei secret esterno come Secret Manager per archiviare dati sensibili, come le chiavi API, al di fuori del cluster.

In Kubernetes, puoi archiviare i dati sensibili nei secret del tuo cluster. Puoi utilizzare i secret per fornire dati riservati alle applicazioni senza includerli nel codice dell'applicazione. Tuttavia, l'archiviazione di questi dati nel cluster presenta rischi come i seguenti:

  • Chiunque possa creare pod in uno spazio dei nomi può leggere i dati di qualsiasi secret in quello spazio dei nomi.
  • Chiunque abbia accesso RBAC o IAM per leggere tutti gli oggetti API Kubernetes può leggere i secret.

A causa di questi rischi, crea i secret nel cluster solo quando non puoi fornire questi dati ai tuoi workload in altro modo. Ti consigliamo i seguenti metodi, in ordine di preferenza, per archiviare e accedere ai tuoi dati sensibili:

  • Librerie client Secret Manager: accedi in modo programmatico ai secret dal codice dell'applicazione utilizzando l'API Secret Manager con la federazione delle identità per i carichi di lavoro per GKE. Per saperne di più, vedi Accedere agli oggetti Secret memorizzati al di fuori dei cluster GKE utilizzando le librerie client.
  • Dati di Secret Manager come volumi montati: fornisci dati sensibili ai tuoi pod come volumi montati utilizzando il componente aggiuntivo Secret Manager per GKE. Questo metodo è utile se non puoi modificare il codice dell'applicazione per utilizzare le librerie client Secret Manager. Per saperne di più, consulta Utilizzare il componente aggiuntivo Secret Manager con Google Kubernetes Engine.

  • Strumenti di gestione dei secret di terze parti: strumenti di terze parti come HashiCorp Vault forniscono funzionalità di gestione dei secret per i carichi di lavoro Kubernetes. Questi strumenti richiedono una configurazione iniziale più complessa rispetto a Secret Manager, ma sono un'opzione più sicura rispetto alla creazione di secret nel cluster. Per configurare uno strumento di terze parti per la gestione dei secret, consulta la documentazione del fornitore. Inoltre, tieni presente i seguenti consigli:

    • Se lo strumento di terze parti viene eseguito in un cluster, utilizza un cluster diverso da quello che esegue i tuoi carichi di lavoro.
    • Utilizza Cloud Storage o Spanner per archiviare i dati dello strumento.
    • Utilizza un bilanciatore del carico di rete passthrough interno per esporre lo strumento di gestione dei secret di terze parti ai pod in esecuzione nella rete VPC.

  • Utilizza i secret di Kubernetes (opzione non consigliata): se nessuna delle opzioni precedenti è adatta al tuo caso d'uso, puoi archiviare i dati come secret di Kubernetes. Google Cloud cripta i dati a livello di archiviazione per impostazione predefinita. Questa crittografia del livello di archiviazione predefinita include il database che memorizza lo stato del cluster, che si basa su etcd o Spanner. Inoltre, puoi criptare questi secret a livello di applicazione con una chiave che gestisci. Per saperne di più, vedi Crittografia dei secret a livello di applicazione.

Sicurezza dei carichi di lavoro

Le sezioni seguenti forniscono suggerimenti per migliorare la sicurezza del cluster contro i problemi dei workload. Gli ingegneri della sicurezza e gli amministratori della piattaforma devono applicare questi suggerimenti per migliorare la protezione dell'infrastruttura GKE dai carichi di lavoro.

Best practice

Isolare i carichi di lavoro utilizzando GKE Sandbox

Consigliato: utilizza GKE Sandbox per impedire che il codice dannoso influisca sul kernel host nei nodi del cluster.

Puoi eseguire i container in un ambiente sandbox per mitigare la maggior parte degli attacchi di container escape, chiamati anche attacchi di escalation dei privilegi locali. Come descritto nei bollettini sulla sicurezza di GKE, questo tipo di attacco consente a un utente malintenzionato di accedere alla VM host del container. L'autore dell'attacco può utilizzare questo accesso host per accedere ad altri container sulla stessa VM. GKE Sandbox può contribuire a limitare l'impatto di questi attacchi.

Utilizza GKE Sandbox in scenari come i seguenti:

  • Hai carichi di lavoro che eseguono codice non attendibile.
  • Vuoi limitare l'impatto se un utente malintenzionato compromette un container nel carico di lavoro.

Per maggiori informazioni, vedi Protezione dell'isolamento del carico di lavoro con GKE Sandbox.

Limitare la capacità dei workload di automodificarsi

Consigliato: utilizza i controller di ammissione per impedire ai workload di modificarsi autonomamente o per impedire la modifica di attributi di workload rischiosi come ServiceAccounts.

Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione per modificarsi autonomamente. Ad esempio, alcuni carichi di lavoro vengono scalati automaticamente in verticale. Sebbene comoda, l'automodifica può consentire a un malintenzionato che ha già compromesso un nodo di ottenere privilegi più elevati nel cluster. Ad esempio, un malintenzionato potrebbe fare in modo che un workload in uno spazio dei nomi venga eseguito come ServiceAccount con più privilegi nello stesso spazio dei nomi.

Se non necessario, non concedere ai pod l'autorizzazione a modificarsi autonomamente. Se alcuni pod devono modificarsi autonomamente, utilizza Policy Controller per limitare ciò che i carichi di lavoro possono modificare. Ad esempio, puoi utilizzare il modello di vincolo NoUpdateServiceAccount per impedire ai pod di modificare il proprio service account. Quando crei un criterio, escludi qualsiasi componente di gestione del cluster dai vincoli, come nel seguente esempio:

parameters:
  allowedGroups:
  - system:masters
  allowedUsers:
  - system:addon-manager

Applicazione basata su policy

Le sezioni seguenti forniscono consigli per l'utilizzo delle policy per applicare vincoli di sicurezza su più risorse. Gli amministratori di identità e account e gli ingegneri della sicurezza devono applicare questi consigli per mantenere la conformità di cluster e carichi di lavoro ai requisiti di sicurezza dell'organizzazione.

Best practice

Applicare i criteri nell'intera gerarchia delle risorse Google Cloud

Consigliato: per applicare le pratiche di sicurezza nella tua organizzazione, cartella o progetto, utilizza Organization Policy Service.

Con Organization Policy, puoi definire centralmente i vincoli e applicarli a vari livelli della gerarchia delle risorse. Diversi Google Cloud prodotti pubblicano vincoli gestiti che ti consentono di applicare i consigli sulle best practice per quel prodotto. Ad esempio, GKE pubblica vincoli gestiti per molte delle best practice descritte in questo documento.

Per saperne di più su come attivare Organization Policy, consulta la pagina Creazione e gestione delle policy dell'organizzazione.

Applicare criteri durante l'ammissione del workload

Consigliato: utilizza un controller di ammissione come Policy Controller o il controller di ammissione PodSecurity per esaminare le richieste API in entrata e applicare i criteri a queste richieste.

I controller di ammissione intercettano le richieste autenticate e autorizzate all'API Kubernetes per eseguire attività di convalida o mutazione prima di consentire la persistenza di una risorsa nell'API.

Puoi utilizzare i seguenti metodi per il controllo dell'ammissione nei cluster GKE:

Gestione dei cluster

Le sezioni seguenti forniscono consigli per la gestione dei cluster nel tempo, ad esempio l'upgrade, il monitoraggio e la configurazione dei log. Gli ingegneri della sicurezza, gli amministratori della piattaforma e gli SRE devono utilizzare questi consigli per mantenere la security posture della piattaforma GKE.

Best practice

Esegui regolarmente l'upgrade dell'infrastruttura GKE

Consigliato: mantieni aggiornata la versione di GKE per accedere a nuove funzionalità di sicurezza e applicare patch di sicurezza. Utilizza i canali di rilascio, gli upgrade automatici delle patch accelerati e gli upgrade automatici dei nodi.

Kubernetes e GKE rilasciano spesso nuove versioni patch che includono miglioramenti della sicurezza e correzioni delle vulnerabilità. Per tutti i cluster, GKE esegue automaticamente l'upgrade del control plane a versioni secondarie e versioni delle patch più stabili.

Per assicurarti che il cluster GKE esegua una versione aggiornata, procedi nel seguente modo:

  • Registra i cluster in un canale di rilascio. I cluster Autopilot sono sempre registrati in un canale di rilascio.
  • Per i cluster che si trovano in un canale di rilascio, attiva gli upgrade automatici delle patch accelerati per ricevere le versioni patch di sicurezza non appena sono disponibili nel tuo canale di rilascio.
  • Per i cluster Standard che non si trovano in un canale di rilascio, attiva gli upgrade automatici dei nodi. L'upgrade automatico dei nodi è abilitato per impostazione predefinita per i cluster creati utilizzando la consoleGoogle Cloud da giugno 2019 e per i cluster creati utilizzando l'API GKE a partire dall'11 novembre 2019.
  • Se utilizzi le policy di manutenzione, utilizza un periodo di manutenzione per consentire a GKE di eseguire l'upgrade automatico dei nodi almeno una volta al mese.
  • Per i node pool che non utilizzano gli upgrade automatici dei nodi, esegui l'upgrade dei node pool almeno una volta al mese in base alla tua pianificazione.
  • Tieni traccia dei bollettini sulla sicurezza di GKE e delle note di rilascio di GKE per informazioni sulle patch di sicurezza.

Attiva le notifiche del bollettino sulla sicurezza

Consigliato: configura le notifiche per i nuovi bollettini sulla sicurezza che interessano il tuo cluster.

Quando sono disponibili bollettini sulla sicurezza pertinenti per il tuo cluster, GKE pubblica notifiche relative a questi eventi come messaggi negli argomenti Pub/Sub che configuri. Puoi ricevere queste notifiche in una sottoscrizione Pub/Sub, integrarle con servizi di terze parti e riceverle in Cloud Logging.

Per applicare questo consiglio nella tua organizzazione, utilizza il constraints/container.managed.enableSecurityBulletinNotifications vincolo della policy dell'organizzazione gestita. Per esaminare questo vincolo gestito nella console Google Cloud , vai alla pagina Dettagli policy.

Vai ai dettagli della policy

Configura la raccolta dei log

Consigliato: per ridurre i costi operativi e mantenere una visualizzazione consolidata dei log, implementa una strategia di logging coerente nei cluster. Non disabilitare la raccolta dei log nei cluster standard.

I cluster GKE inviano log specifici a Google Cloud Observability. Facoltativamente, puoi configurare la raccolta di tipi di log aggiuntivi. Oltre ai log di sistema e dei carichi di lavoro, tutti i cluster GKE inviano i seguenti audit log a Logging:

  • Audit log di Kubernetes: un record cronologico delle chiamate effettuate al server dell'API Kubernetes. Le voci degli audit log di Kubernetes sono utili per esaminare richieste API sospette, raccogliere statistiche o creare avvisi di monitoraggio per chiamate API indesiderate.
  • Audit log di GKE: un record delle attività amministrative e di accesso per l'API GKE.

Per saperne di più, consulta i seguenti documenti:

Per applicare questo consiglio nella tua organizzazione, utilizza il constraints/container.managed.enableCloudLogging vincolo della policy dell'organizzazione gestita. Per esaminare questo vincolo gestito nella console Google Cloud , vai alla pagina Dettagli policy.

Vai ai dettagli della policy

Monitorare le risorse per rilevare eventuali problemi di sicurezza

Utilizza la dashboard sulla postura di sicurezza di GKE e Security Command Center per monitorare i cluster e i carichi di lavoro per potenziali problemi. Puoi utilizzare questi servizi per verificare la presenza di vulnerabilità attive, minacce e bollettini sulla sicurezza che interessano la tua infrastruttura GKE.

Configurazioni di sicurezza predefinite

Le sezioni seguenti descrivono le opzioni configurate per impostazione predefinita nei nuovi cluster per mitigare problemi di sicurezza specifici, come vulnerabilità o rischi. Gli ingegneri della sicurezza e gli amministratori della piattaforma devono verificare che i cluster esistenti utilizzino queste impostazioni.

Best practice

Lascia disabilitati i metodi di autenticazione client legacy

Consigliato: disattiva i metodi di autenticazione del server API legacy come certificati e password statici.

Esistono diversi metodi di autenticazione al server dell'API Kubernetes. In GKE, i metodi supportati sono i token di autenticazione dell'account di servizio, i token OAuth e i certificati client X.509. gcloud CLI utilizza i token OAuth per autenticare gli utenti per GKE.

I metodi di autenticazione legacy come le password statiche sono disabilitati perché aumentano la superficie di attacco per i compromissioni del cluster. Nei cluster Autopilot non puoi attivare o utilizzare questi metodi di autenticazione.

Utilizza uno dei seguenti metodi per l'autenticazione nel server dell'API Kubernetes:

  • Utenti: utilizza gcloud CLI per consentire a GKE di autenticare gli utenti, generare token di accesso OAuth per il cluster e mantenere aggiornati i token.
  • Applicazioni: utilizza la federazione di Workload Identity per consentire alle applicazioni in Google Cloud o in altri ambienti di autenticarsi al tuo cluster.

Per saperne di più su come autenticarsi e disattivare i metodi di autenticazione legacy, vedi Autenticarsi nel server dell'API Kubernetes.

Per applicare questo consiglio nella tua organizzazione, utilizza il constraints/container.managed.disableLegacyClientCertificateIssuance vincolo della policy dell'organizzazione gestita. Per esaminare questo vincolo gestito nella console Google Cloud , vai alla pagina Dettagli policy.

Vai ai dettagli della policy

Lascia ABAC disattivato

Consigliato: utilizza IAM e RBAC per controllare l'accesso in GKE. Non abilitare il controllo dell'accesso basato su attributi (ABAC).

ABAC è un metodo di autorizzazione legacy disabilitato per impostazione predefinita in tutti i cluster GKE e non può essere abilitato nei cluster Autopilot.

Per applicare questo consiglio nella tua organizzazione, utilizza il constraints/container.managed.disableABAC vincolo della policy dell'organizzazione gestita. Per esaminare questo vincolo gestito nella console Google Cloud , vai alla pagina Dettagli policy.

Vai ai dettagli della policy

Lascia abilitato il controller di ammissione DenyServiceExternalIPs

Azione consigliata: non disattivare il controller di ammissione DenyServiceExternalIPs.

Questo admission controller impedisce ai servizi di utilizzare ExternalIPs e mitiga GCP-2020-015. Questo controller di ammissione è abilitato per impostazione predefinita nei cluster creati su GKE versione 1.21 e successive. Per i cluster creati originariamente su una versione precedente di GKE, abilita il controller di ammissione:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips
Per applicare questo consiglio nella tua organizzazione, utilizza il constraints/container.managed.denyServiceExternalIPs vincolo della policy dell'organizzazione gestita. Per esaminare questo vincolo gestito nella console Google Cloud , vai alla pagina Dettagli policy.

Vai ai dettagli della policy

Passaggi successivi