Rafforza la sicurezza del cluster

Questa pagina ti guida nell'implementazione delle best practice attuali per proteggere il tuo cluster Google Kubernetes Engine (GKE). Questa guida dà la priorità alle mitigazioni di sicurezza di alto valore che richiedono l'intervento del cliente al momento della creazione del cluster. Le funzionalità meno critiche, le impostazioni sicure per impostazione predefinita e quelle che possono essere attivate dopo la creazione sono menzionate più avanti nel documento.

Questo documento è destinato agli esperti di sicurezza che definiscono, gestiscono e implementano policy e procedure per proteggere i dati di un'organizzazione da accessi non autorizzati. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti, consulta Ruoli e attività comuni degli utenti GKE. Google Cloud

Prima di leggere questa pagina, assicurati di avere familiarità con quanto segue:

• Panoramica generale della sicurezza di GKE
• Consiglio per il benchmark CIS GKE

Se crei nuovi cluster in GKE, molte di queste protezioni sono abilitate per impostazione predefinita. Se esegui l'upgrade dei cluster esistenti, assicurati di rivedere regolarmente questa guida al rafforzamento e di attivare le nuove funzionalità.

I cluster creati in modalità Autopilot implementano molte funzionalità di hardening di GKE per impostazione predefinita.

Molti di questi consigli, così come altri errori di configurazione comuni, possono essere controllati automaticamente utilizzando Security Health Analytics.

Esegui regolarmente l'upgrade dell'infrastruttura GKE

Consiglio di CIS GKE Benchmark: 6.5.3. Assicurati che l'upgrade automatico dei nodi sia abilitato per i nodi GKE

Mantenere aggiornata la versione di Kubernetes è una delle cose più semplici che puoi fare per migliorare la sicurezza. Kubernetes introduce spesso nuove funzionalità di sicurezza e fornisce patch di sicurezza.

Consulta i bollettini sulla sicurezza di GKE per informazioni sulle patch di sicurezza.

In Google Kubernetes Engine, le patch e gli upgrade dei piani di controllo vengono eseguiti automaticamente. L'upgrade automatico dei nodi esegue anche l'upgrade automatico dei nodi nel cluster.

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 a partire dall'11 novembre 2019.

Se scegli di disabilitare l'upgrade automatico dei nodi, ti consigliamo di eseguire l'upgrade mensile in base alla tua pianificazione. I cluster meno recenti devono attivare l'upgrade automatico dei nodi e seguire attentamente i bollettini sulla sicurezza di GKE per le patch critiche.

Per saperne di più, consulta la sezione Upgrade automatico dei nodi.

Limita l'accesso di rete al control plane e ai nodi

Consigli di CIS GKE Benchmark: 6.6.2. Preferisci i cluster nativi di VPC, 6.6.3. Assicurati che le reti autorizzate siano abilitate, 6.6.4. Assicurati che i cluster vengano creati con endpoint privato abilitato e accesso pubblico disabilitato e 6.6.5. Assicurati che i cluster vengano creati con nodi privati

Per impostazione predefinita, il control plane e i nodi del cluster GKE hanno indirizzi instradabili su internet a cui è possibile accedere da qualsiasi indirizzo IP.

Limitare l'accesso al control plane

Per limitare l'accesso al control plane del cluster GKE, consulta Configurare l'accesso al control plane. Di seguito sono riportate le opzioni disponibili per la protezione a livello di rete:

• Endpoint basato su DNS abilitato (consigliato): puoi controllare chi può accedere all'endpoint basato su DNS con Controlli di servizio VPC. I Controlli di servizio VPC ti consentono di definire un parametro di sicurezza per tutte le API Google nel tuo progetto con attributi sensibili al contesto, come l'origine di rete. Queste impostazioni possono essere controllate centralmente per un progetto in tutte le API di Google, riducendo il numero di posizioni in cui devi configurare le regole di accesso.

• Accesso agli endpoint basati su IP esterni e interni disabilitato:impedisce tutto l'accesso al control plane tramite endpoint basati su IP.

• Accesso all'endpoint basato su IP esterno disabilitato: impedisce l'accesso a internet a entrambi i control plane. Questa è una buona scelta se hai configurato la tua rete on-premise per connettersi a Google Cloud utilizzando Cloud Interconnect e Cloud VPN. Queste tecnologie connettono in modo efficace la rete aziendale al VPC cloud.

• Accesso all'endpoint basato su IP esterno abilitato, reti autorizzate abilitate: questa opzione fornisce un accesso limitato al control plane dagli indirizzi IP di origine che definisci. Questa è una buona scelta se non disponi di un'infrastruttura VPN esistente o se hai utenti remoti o filiali che si connettono tramite internet pubblico anziché tramite la VPN aziendale e Cloud Interconnect o Cloud VPN.

• Accesso all'endpoint esterno abilitato, reti autorizzate disabilitate: chiunque su internet può stabilire connessioni di rete al control plane.

Se utilizzi endpoint basati su IP, ti consigliamo di utilizzare reti autorizzate per i cluster.

In questo modo, il control plane è raggiungibile da:

• I CIDR consentiti nelle reti autorizzate.
• Nodi all'interno del VPC del cluster.
• Indirizzi IP riservati a Google per la gestione dei cluster.

Limitare l'accesso ai nodi

Per disabilitare l'accesso diretto a internet ai nodi, specifica l'opzione gcloud CLI --enable-private-nodes durante la creazione del cluster.

In questo modo, GKE esegue il provisioning dei nodi con indirizzi IP interni, il che significa che i nodi non sono raggiungibili direttamente tramite la rete internet pubblica.

Limitare l'accesso anonimo agli endpoint del cluster

Questo miglioramento della sicurezza contribuisce a mitigare i rischi associati al binding di ruoli accidentale o dannoso limitando l'accesso anonimo agli endpoint del cluster. Per impostazione predefinita, Kubernetes assegna l'utente system:anonymous e il gruppo system:unauthenticated alle richieste anonime agli endpoint del cluster. Se l'utente o il gruppo dispone di autorizzazioni nel cluster tramite associazioni RBAC, potrebbe concedere a un utente anonimo l'accesso non intenzionale a endpoint che possono essere utilizzati per compromettere la sicurezza di un servizio o del cluster stesso.

A meno che non siano esplicitamente limitate tramite i binding RBAC, le richieste di autenticazione anonima vengono accettate per tutti gli endpoint del cluster. Nella versione 1.32.2-gke.1234000 e successive di GKE, quando crei o aggiorni un cluster, puoi limitare l'insieme di endpoint che le richieste anonime possono raggiungere solo ai tre endpoicontrollo di integritàllo dell'integrità del server API Kubernetes: /healthz, /livez e /readyz. L'accesso anonimo a questi endpoint di controllo di integrità'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 in uno dei seguenti comandi gcloud CLI:

• gcloud container clusters create
• gcloud container clusters create-auto
• gcloud container clusters update

Il flag --anonymous-authentication-config accetta il valore LIMITED o ENABLED. Il valore predefinito è ENABLED. Quando imposti il valore su LIMITED, le richieste anonime vengono rifiutate durante l'autenticazione anche se tale accesso è consentito dalle associazioni RBAC esistenti. Le richieste rifiutate restituiscono uno stato HTTP 401.

Come mostrato nell'esempio seguente, puoi utilizzare un vincolo della policy dell'organizzazione per applicare questa restrizione di accesso nei cluster della tua organizzazione:

name: organizations/ORGANIZATION_ID/customConstraints/custom.gkeAnonymousAccessLimited
    resourceTypes:
    - container.googleapis.com/Cluster
    methodTypes:
    - CREATE
    - UPDATE
    condition: "condition:resource.anonymousAuthenticationConfig.mode == "LIMITED"
    action: ALLOW
    displayName: Restrict anonymous access to cluster endpoints.
    description: All new and updated clusters must restrict anonymous access to cluster endpoints.

Sostituisci ORGANIZATION_ID con l'ID organizzazione, ad esempio 123456789.

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

• Limitare l'accesso al control plane
• Abilita nodi privati
• Evitare ruoli e gruppi predefiniti

Per informazioni sull'implementazione di Kubernetes sottostante per questo miglioramento, consulta Configurazione dell'autenticatore anonimo. Per ulteriori informazioni sulle norme di controllo dell'accesso basato sui ruoli (RBAC), consulta Best practices for GKE RBAC.

Utilizza regole firewall con privilegi minimi

Riduci al minimo il rischio di accesso involontario utilizzando il principio del privilegio minimo per le regole firewall

GKE crea regole firewall VPC predefinite per abilitare la funzionalità di sistema e applicare buone pratiche di sicurezza. Per un elenco completo delle regole firewall create automaticamente, consulta la sezione Regole firewall create automaticamente.

GKE crea queste regole firewall predefinite con una priorità di 1000. Se crei regole firewall permissive con una priorità più alta, ad esempio una regola firewall allow-all per il debug, il tuo cluster è a rischio di accesso non intenzionale.

Utilizza l'autenticazione di gruppo

Consiglio di CIS GKE Benchmark: 6.8.3. Valuta la possibilità di gestire gli utenti RBAC di Kubernetes con Google Gruppi per RBAC

Devi utilizzare i gruppi per gestire gli utenti. L'utilizzo dei gruppi consente di controllare le identità utilizzando il sistema di gestione delle identità e gli amministratori delle identità. La modifica dell'iscrizione al gruppo elimina la necessità di aggiornare la configurazione RBAC ogni volta che qualcuno viene aggiunto o rimosso dal gruppo.

Per gestire le autorizzazioni utente utilizzando Google Gruppi, devi abilitare Google Gruppi per RBAC sul tuo cluster. In questo modo puoi gestire gli utenti con le stesse autorizzazioni, consentendo agli amministratori delle identità di gestire gli utenti in modo centralizzato e coerente.

Consulta Google Gruppi per RBAC per istruzioni su come abilitare Google Gruppi per RBAC.

Configura la sicurezza per i nodi container

Le sezioni seguenti descrivono le scelte di configurazione dei nodi sicuri.

Abilita Shielded GKE Nodes

Consiglio di CIS GKE Benchmark: 6.5.5. Assicurati che Shielded GKE Nodes sia abilitato

I nodi GKE schermati forniscono un'identità e un'integrità del nodo solide e verificabili per aumentare la sicurezza dei nodi GKE e devono essere abilitati su tutti i cluster GKE.

Puoi abilitare i nodi GKE schermati durante la creazione o l'aggiornamento del cluster. Shielded GKE Nodes deve essere abilitato con l'avvio protetto. L'avvio protetto non deve essere utilizzato se hai bisogno di moduli del kernel non firmati di terze parti. Per istruzioni su come abilitare Shielded GKE Nodes e l'avvio protetto con Shielded GKE Nodes, consulta Utilizzo di Shielded GKE Nodes.

Scegliere un'immagine del nodo sottoposta a hardening con il runtime containerd

L'immagine di Container-Optimized OS con containerd (cos_containerd) è una variante dell'immagine di Container-Optimized OS in cui containerd rappresenta il runtime del container principale direttamente integrato con Kubernetes.

containerd è il componente di runtime principale di Docker ed è stato progettato per fornire la funzionalità di base del container per l'interfaccia di runtime del container (CRI) di Kubernetes. È molto meno complesso del daemon Docker completo e pertanto ha una superficie di attacco più piccola.

Per utilizzare l'immagine cos_containerd nel cluster, consulta Immagini Containerd.

L'immagine cos_containerd è l'immagine preferita per GKE perché è stata creata, ottimizzata e protetta appositamente per l'esecuzione di container.

Abilita la federazione delle identità per i workload per GKE

Consiglio CIS GKE Benchmark: 6.2.2. Preferisci l'utilizzo di service account Google Cloud dedicati e Workload Identity

Workload Identity Federation for GKE è il modo consigliato per autenticarsi alle API Google Cloud .

La federazione delle identità per i carichi di lavoro per GKE sostituisce la necessità di utilizzare l'occultamento dei metadati e, pertanto, i due approcci sono incompatibili. I metadati sensibili protetti dall'occultamento dei metadati sono protetti anche da Workload Identity Federation for GKE.

Protezione dell'isolamento del carico di lavoro con GKE Sandbox

Consiglio di CIS GKE Benchmark: 6.10.4. Valuta l'utilizzo di GKE Sandbox per rafforzare l'isolamento dei carichi di lavoro, in particolare per i carichi di lavoro non attendibili

GKE Sandbox fornisce un ulteriore livello di sicurezza per impedire che il codice dannoso influisca sul kernel host sui nodi del cluster.

Puoi eseguire i container in un ambiente sandbox per ridurre la maggior parte degli attacchi di container escape, chiamati anche attacchi di escalation dei privilegi locali. Per le vulnerabilità di container escape passate, consulta i bollettini sulla sicurezza. Questo tipo di attacco consente a un malintenzionato di accedere alla VM host del container e quindi di accedere ad altri container sulla stessa VM. Una sandbox come GKE Sandbox può contribuire a limitare l'impatto di questi attacchi.

Ti consigliamo di eseguire il sandboxing di un workload in situazioni come:

• Il workload esegue codice non attendibile
• Vuoi limitare l'impatto se un utente malintenzionato compromette un container nel carico di lavoro.

Scopri come utilizzare GKE Sandbox in Protezione dell'isolamento del carico di lavoro con GKE Sandbox.

Attiva le notifiche del bollettino sulla sicurezza

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 filtrare in base ai tipi di notifiche che vuoi ricevere.

Per saperne di più sulla ricezione di bollettini sulla sicurezza tramite le notifiche dei cluster GKE, consulta Notifiche dei cluster.

Disabilita la porta di sola lettura kubelet non sicura

Disabilita la porta di sola lettura di kubelet e passa tutti i carichi di lavoro che utilizzano la porta 10255 per utilizzare la 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 gestisce gli stessi endpoint sulla porta autenticata e più sicura 10250.

Per istruzioni, consulta la pagina Disabilita la porta di sola lettura di kubelet nei cluster GKE.

Concedere le autorizzazioni di accesso

Le sezioni seguenti descrivono come concedere l'accesso alla tua infrastruttura GKE.

Utilizza i service account IAM con privilegio minimo

Consiglio di CIS GKE Benchmark: 6.2.1. Preferisci non eseguire cluster GKE utilizzando il service account predefinito di Compute Engine

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 del tuo progetto o della 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 creare un account di servizio personalizzato e concedergli il ruolo richiesto per GKE, completa i seguenti passaggi:

resource "google_service_account" "default" {
  account_id   = "gke-node-service-account"
  display_name = "GKE node service account"
}

data "google_project" "project" {
}

resource "google_project_iam_member" "default" {
  project = data.google_project.project.project_id
  role    = "roles/container.defaultNodeServiceAccount"
  member  = "serviceAccount:${google_service_account.default.email}"
}

Puoi utilizzare questo account di servizio anche per le risorse in altri progetti. Per le istruzioni, vedi Abilitare la simulazione dell'identità degli account di servizio tra progetti.

Concedere l'accesso ai repository di immagini privati

Per utilizzare immagini private in Artifact Registry, concedi il ruolo Lettore di Artifact Registry (roles/artifactregistry.reader) al account di servizio.

gcloud artifacts repositories add-iam-policy-binding REPOSITORY_NAME \
    --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/artifactregistry.reader

Se utilizzi immagini private in Container Registry, devi anche concedere l'accesso a queste immagini:

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
  --member=serviceAccount:SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/storage.objectViewer

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-object-viewer
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/storage.objectViewer
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

kubectl apply -f policy-object-viewer.yaml

Se vuoi che un altro utente umano possa creare nuovi cluster o pool di nodi con questo account di servizio, devi concedergli il ruolo Utente service account per questo account di servizio:

gcloud iam service-accounts add-iam-policy-binding \
    SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --member=user:USER \
    --role=roles/iam.serviceAccountUser

apiVersion: iam.cnrm.cloud.google.com/v1beta1
kind: IAMPolicyMember
metadata:
  name: policy-service-account-user
spec:
  member: serviceAccount:[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
  role: roles/iam.serviceAccountUser
  resourceRef:
    kind: Project
    name: [PROJECT_ID]

kubectl apply -f policy-service-account-user.yaml

Per i cluster Standard esistenti, ora puoi creare un nuovo pool di nodi con questo nuovoaccount di serviziot. Per i cluster Autopilot, devi creare un nuovo cluster con l'account di servizio. Per istruzioni, vedi Creazione di un cluster Autopilot.

• Crea un pool di nodi che utilizza il nuovo account di servizio:

  gcloud container node-pools create NODE_POOL_NAME \
  --service-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
  --cluster=CLUSTER_NAME

Se devi consentire al tuo cluster GKE di accedere ad altri servizi Google Cloud, devi utilizzare Workload Identity Federation for GKE.

Limita l'accesso al rilevamento delle API del cluster

Per impostazione predefinita, Kubernetes esegue il bootstrap dei cluster con un insieme permissivo di ClusterRoleBinding di rilevamento che forniscono un ampio accesso alle informazioni sulle API di un cluster, incluse quelle di CustomResourceDefinitions.

Gli utenti devono essere consapevoli che il gruppo system:authenticated incluso nei soggetti di system:discovery e system:basic-user ClusterRoleBindings può includere qualsiasi utente autenticato (incluso qualsiasi utente con un Account Google) e non rappresenta un livello di sicurezza significativo per i cluster su GKE. Per saperne di più, vedi Evitare ruoli e gruppi predefiniti.

Chi vuole proteggere le API di rilevamento del proprio cluster deve prendere in considerazione una o più delle seguenti opzioni:

• Abilita solo l'endpoint basato su DNS per l'accesso al control plane.
• Configura le reti autorizzate per limitare l'accesso a intervalli IP impostati.
• Limita l'accesso al control plane e abilita i nodi privati.

Se nessuna di queste opzioni è adatta al tuo caso d'uso di GKE, devi considerare tutte le informazioni di rilevamento delle API (ovvero lo schema di CustomResources, le definizioni di APIService e le informazioni di rilevamento ospitate dai server API di estensione) come divulgate pubblicamente.

Utilizzare gli spazi dei nomi e RBAC per limitare l'accesso alle risorse del cluster

Consiglio CIS GKE Benchmark: 5.6.1. Crea confini amministrativi tra le risorse utilizzando gli spazi dei nomi

Concedi ai team l'accesso minimo a Kubernetes creando spazi dei nomi o cluster separati per ogni team e ambiente. Assegna centri di costo ed etichette appropriate a ogni spazio dei nomi per responsabilità e riaddebiti. Concedi agli sviluppatori solo il livello di accesso allo spazio dei nomi necessario per eseguire il deployment e gestire l'applicazione, soprattutto in produzione. Mappa le attività che i tuoi utenti devono svolgere nel cluster e definisci le autorizzazioni di cui hanno bisogno per svolgere ogni attività.

Per ulteriori informazioni sulla creazione di spazi dei nomi, consulta la documentazione di Kubernetes. Per le best practice per la pianificazione della configurazione RBAC, consulta Best practice per RBAC in GKE.

IAM e il controllo controllo dell'accesso basato sui ruoli (RBAC) funzionano insieme e un'entità deve disporre di autorizzazioni sufficienti a uno dei due livelli per interagire con le risorse nel cluster.

Assegna i ruoli IAM appropriati per GKE a gruppi e utenti per fornire le autorizzazioni a livello di progetto e utilizza RBAC per concedere le autorizzazioni a livello di cluster e spazio dei nomi. Per saperne di più, consulta Controllo dell'accesso.

Limitare il traffico tra i pod con una policy di rete

Consiglio di CIS GKE Benchmark: 6.6.7. Assicurati che i criteri di rete siano abilitati e impostati in modo appropriato

Per impostazione predefinita, tutti i pod di un cluster possono comunicare tra loro. Devi controllare la comunicazione tra pod in base alle esigenze dei tuoi carichi di lavoro.

Limitare l'accesso di rete ai servizi rende molto più difficile per gli autori di attacchi spostarsi lateralmente all'interno del cluster e offre anche ai servizi una protezione contro il denial of service accidentale o intenzionale. Due modi consigliati per controllare il traffico sono:

1. Utilizza Istio. Consulta Installazione di Istio su Google Kubernetes Engine se ti interessano il bilanciamento del carico, l'autorizzazione dei servizi, la limitazione, la quota, le metriche e altro ancora.
2. Utilizza i criteri di rete di Kubernetes. Consulta Creazione di un criterio di rete per il cluster. Scegli questa opzione se cerchi la funzionalità di controllo dell'accesso di base esposta da Kubernetes. Per implementare approcci comuni per limitare il traffico utilizzando i criteri di rete, segui la guida all'implementazione dei blueprint di sicurezza di GKE Enterprise. Inoltre, la documentazione di Kubernetes offre un'ottima procedura dettagliata per un semplice deployment di nginx. Valuta la possibilità di utilizzare la registrazione dei criteri di rete per verificare che i criteri di rete funzionino come previsto.

Istio e i criteri di rete possono essere utilizzati insieme, se necessario.

Proteggere i dati con la gestione dei secret

Consiglio di CIS GKE Benchmark: 6.3.1. Valuta la possibilità di criptare i secret di Kubernetes utilizzando chiavi gestite in Cloud KMS

Utilizza uno strumento di gestione dei secret esterno per archiviare i dati sensibili al di fuori del cluster e accedere a questi dati in modo programmatico.

In Kubernetes, puoi archiviare dati sensibili negli oggetti Secret del tuo cluster. I secret ti consentono di 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.

Se possibile, utilizza un servizio di gestione dei secret esterno, ad esempio Secret Manager, per archiviare i dati sensibili al di fuori del cluster. Crea secret nel cluster solo quando non puoi fornire questi dati ai tuoi carichi di lavoro in altro modo. Ti consigliamo i seguenti metodi, in ordine di preferenza, per accedere ai tuoi secret:

• 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 ulteriori informazioni, 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 maggiore 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, prendi in considerazione i seguenti consigli:

  • Se lo strumento di terze parti viene eseguito in un cluster, utilizza un cluster diverso da quello che esegue i 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 tua 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 predefinita del livello di archiviazione include il database che memorizza lo stato del cluster, basato 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.

Utilizzare i controller di ammissione per applicare i criteri

I controller di ammissione sono plug-in che regolano e applicano le modalità di utilizzo del cluster. Devono essere abilitati per utilizzare alcune delle funzionalità di sicurezza più avanzate di Kubernetes e sono una parte importante dell'approccio di difesa in profondità per rafforzare il cluster

Per impostazione predefinita, i pod in Kubernetes possono operare con funzionalità superiori a quelle richieste. Devi limitare le funzionalità del pod solo a quelle richieste per il carico di lavoro.

Kubernetes supporta numerosi controlli per limitare l'esecuzione dei pod solo con le funzionalità concesse esplicitamente. Ad esempio, Policy Controller è disponibile per i cluster nei parchi risorse. Kubernetes dispone anche del controller di ammissione PodSecurity integrato che ti consente di applicare gli standard di sicurezza dei pod nei singoli cluster.

Policy Controller è una funzionalità di GKE Enterprise che ti consente di applicare e convalidare la sicurezza sui cluster GKE su larga scala utilizzando criteri dichiarativi. Per scoprire come utilizzare Policy Controller per applicare controlli dichiarativi sul tuo cluster GKE, consulta Installare Policy Controller.

Il controller di ammissione PodSecurity ti consente di applicare criteri predefiniti in spazi dei nomi specifici o nell'intero cluster. Questi criteri corrispondono ai diversi standard di sicurezza dei pod.

Limitare la possibilità per i workload di modificarsi autonomamente

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 comodo, questo 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 sul nodo venga eseguito come un account di servizio con più privilegi che esiste nello stesso spazio dei nomi.

Idealmente, ai workload non dovrebbe essere concessa l'autorizzazione a modificarsi in primo luogo. Quando è necessaria l'automodifica, puoi limitare le autorizzazioni applicando i vincoli di Gatekeeper o Policy Controller, ad esempio NoUpdateServiceAccount dalla libreria open source Gatekeeper, che fornisce diverse norme di sicurezza utili.

Quando implementi i criteri, in genere è necessario consentire ai controller che gestiscono il ciclo di vita del cluster di ignorare i criteri. Questo è necessario affinché i controller possano apportare modifiche al cluster, ad esempio applicare gli upgrade del cluster. Ad esempio, se esegui il deployment del criterio NoUpdateServiceAccount su GKE, devi impostare i seguenti parametri in Constraint:

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

Limitare l'utilizzo del tipo di volume gcePersistentDisk ritirato

Il tipo di volume gcePersistentDisk ritirato consente di montare un disco permanente di Compute Engine sui pod. Ti consigliamo di limitare l'utilizzo del tipo di volume gcePersistentDisk nei tuoi carichi di lavoro. GKE non esegue alcun controllo di autorizzazione IAM sul pod durante il montaggio di questo tipo di volume, anche se Google Cloud esegue controlli di autorizzazione quando collega il disco alla VM sottostante. Un malintenzionato che ha già la possibilità di creare pod in un namespace può quindi accedere ai contenuti dei dischi permanenti di Compute Engine nel tuo progetto Google Cloud .

Per accedere ai dischi permanenti di Compute Engine e utilizzarli, utilizza PersistentVolumes e PersistentVolumeClaim. Applica criteri di sicurezza nel tuo cluster che impediscono l'utilizzo del tipo di volume gcePersistentDisk.

Per impedire l'utilizzo del tipo di volume gcePersistentDisk, applica il criterio Baseline o Restricted con il controller di ammissione PodSecurity oppure puoi definire un vincolo personalizzato in Policy Controller o nel controller di ammissione Gatekeeper.

Per definire un vincolo personalizzato per limitare questo tipo di volume, procedi nel seguente modo:

1. Installa un controller di ammissione basato su criteri come Policy Controller o Gatekeeper OPA.

   Policy Controller

   Installa Policy Controller nel tuo cluster.

   Policy Controller è una funzionalità a pagamento per gli utenti GKE. Policy Controller si basa su Gatekeeper open source, ma hai anche accesso alla libreria completa di modelli di vincolo, ai pacchetti di policy e all'integrazione con le dashboard della console Google Cloud per osservare e gestire i cluster. I bundle di criteri sono best practice soggettive che puoi applicare ai tuoi cluster, inclusi i bundle basati su consigli come il benchmark CIS Kubernetes.

   Gatekeeper

   Installa Gatekeeper nel cluster.

   Per i cluster Autopilot, apri il manifest gatekeeper.yaml di Gatekeeper in un editor di testo. Modifica il campo rules nella specifica MutatingWebhookConfiguration per sostituire i caratteri jolly (*) con gruppi API e nomi di risorse specifici, come nell'esempio seguente:

   apiVersion: admissionregistration.k8s.io/v1
   kind: MutatingWebhookConfiguration
   ...
   webhooks:
   - admissionReviewVersions:
     - v1
     - v1beta1
     ...
     rules:
     - apiGroups:
       - core
       - batch
       - apps
       apiVersions:
       - '*'
       operations:
       - CREATE
       - UPDATE
       resources:
       - Pod
       - Deployment
       - Job
       - Volume
       - Container
       - StatefulSet
       - StorageClass
       - Secret
       - ConfigMap
     sideEffects: None
     timeoutSeconds: 1
   

   Applica il manifest gatekeeper.yaml aggiornato al cluster Autopilot per installare Gatekeeper. Questa operazione è obbligatoria perché, come misura di sicurezza integrata, Autopilot non consente caratteri jolly nei webhook di ammissione mutanti.

2. Esegui il deployment di ConstraintTemplate dei tipi di volume del criterio di sicurezza dei pod integrato:

   kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper-library/master/library/pod-security-policy/volumes/template.yaml
   

3. Salva il seguente vincolo con un elenco di tipi di volumi consentiti come constraint.yaml:

   apiVersion: constraints.gatekeeper.sh/v1beta1
   kind: k8sPSPVolumeTypes
   metadata:
     name: nogcepersistentdisk
   spec:
     match:
       kinds:
         - apiGroups: [""]
           kinds: ["Pods"]
     parameters:
       volumes: ["configMap", "csi", "projected", "secret", "downwardAPI", "persistentVolumeClaim", "emptyDir", "nfs", "hostPath"]
   

   Questo vincolo limita i volumi all'elenco nel campo spec.parameters.volumes.

4. Esegui il deployment del vincolo:

   kubectl apply -f constraint.yaml
   

Monitorare la configurazione del cluster

Devi controllare le configurazioni del cluster per verificare eventuali deviazioni dalle impostazioni definite.

Molti dei consigli trattati in questa guida al rafforzamento, nonché altre configurazioni errate comuni, possono essere controllati automaticamente utilizzando Security Health Analytics.

Esaminare le opzioni sicure predefinite

Le sezioni seguenti descrivono le opzioni configurate in modo sicuro per impostazione predefinita nei nuovi cluster. Devi verificare che i cluster preesistenti siano configurati in modo sicuro.

Proteggere i metadati dei nodi

Suggerimenti per CIS GKE Benchmark: 6.4.1. Assicurati che le API per i metadati legacy delle istanze di Compute Engine siano disattivate e 6.4.2. Assicurati che il server di metadati GKE sia abilitato

Gli endpoint del server di metadati di Compute Engine v0.1 e v1beta1 sono stati deprecati e disattivati il 30 settembre 2020. Questi endpoint non applicavano le intestazioni di query di metadati. Per la programmazione della disattivazione, consulta Deprecazione degli endpoint del server di metadati v0.1 e v1beta1.

Alcuni attacchi pratici contro Kubernetes si basano sull'accesso al server di metadati della VM per estrarre le credenziali. Questi attacchi vengono bloccati se utilizzi la federazione delle identità per i carichi di lavoro per GKE o l'occultamento dei metadati.

Lascia disabilitati i metodi di autenticazione client legacy

Suggerimenti per il benchmark CIS GKE: 6.8.1. Assicurati che l'autenticazione di base tramite password statiche sia disabilitata e 6.8.2. Assicurati che l'autenticazione mediante certificati client sia disabilitata

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 x509. GKE gestisce l'autenticazione con gcloud per te utilizzando il metodo del token OAuth, configurando Kubernetes, ottenendo un token di accesso e mantenendolo aggiornato.

Prima dell'integrazione di GKE con OAuth, l'unico metodo di autenticazione disponibile era un certificato x509 o una password statica generati una sola volta, ma ora non sono consigliati e devono essere disattivati. Questi metodi presentano una superficie di attacco più ampia per la compromissione del cluster e sono stati disattivati per impostazione predefinita a partire dalla versione 1.12 di GKE. Se utilizzi metodi di autenticazione legacy, ti consigliamo di disattivarli. L'autenticazione con una password statica è deprecata ed è stata rimossa a partire dalla versione 1.19 di GKE.

I cluster esistenti devono passare a OAuth. Se un sistema esterno al cluster richiede una credenziale di lunga durata, ti consigliamo di creare un account di servizio Google o un account di servizio Kubernetes con i privilegi necessari ed esportare la chiave.

Per aggiornare un cluster esistente e rimuovere la password statica, consulta Disattivazione dell'autenticazione con una password statica.

Al momento, non è possibile rimuovere il certificato client pre-emesso da un cluster esistente, ma non dispone di autorizzazioni se RBAC è abilitato e ABAC è disabilitato.

Lasciare abilitato Cloud Logging

Consiglio di CIS GKE Benchmark: 6.7.1. Assicurati che Stackdriver Kubernetes Logging and Monitoring sia abilitato

Per ridurre i costi operativi e mantenere una visualizzazione consolidata dei log, implementa una strategia di logging coerente ovunque vengano implementati i cluster. I cluster GKE Enterprise sono integrati con Cloud Logging per impostazione predefinita e devono rimanere configurati.

Tutti i cluster GKE hanno la registrazione degli audit di Kubernetes abilitata per impostazione predefinita, che mantiene un registro cronologico delle chiamate effettuate al server API Kubernetes. Le voci degli audit log di Kubernetes sono utili per esaminare richieste API sospette, per raccogliere statistiche o per creare avvisi di monitoraggio per chiamate API indesiderate.

I cluster GKE integrano Kubernetes Audit Logging con Cloud Audit Logs e Cloud Logging. I log possono essere instradati da Cloud Logging ai tuoi sistemi di logging.

Lascia disabilitata la UI web di Kubernetes (dashboard)

Consiglio di CIS GKE Benchmark: 6.10.1. Assicurati che la UI web di Kubernetes sia disabilitata

Non devi abilitare la UI web (dashboard) di Kubernetes quando esegui GKE.

La UI web di Kubernetes (dashboard) è supportata da un service account Kubernetes con privilegi elevati. La Google Cloud console offre gran parte delle stesse funzionalità, quindi non hai bisogno di queste autorizzazioni.

Per disattivare la UI web di Kubernetes:

gcloud container clusters update CLUSTER_NAME \
    --update-addons=KubernetesDashboard=DISABLED

Lascia ABAC disattivato

Consiglio di CIS GKE Benchmark: 6.8.4. Assicurati che l'autorizzazione legacy (ABAC) sia disabilitata

Devi disabilitare il controllo dell'accesso basato su attributi (ABAC) e utilizzare invece il controllo dell'accesso basato sui ruoli (RBAC) in GKE.

Per impostazione predefinita, ABAC è disabilitato per i cluster creati utilizzando GKE versione 1.8 e successive. In Kubernetes, RBAC viene utilizzato per concedere le autorizzazioni alle risorse a livello di cluster e spazio dei nomi. RBAC consente di definire i ruoli con regole che contengono un insieme di autorizzazioni. RBAC offre vantaggi significativi in termini di sicurezza rispetto ad ABAC.

Se utilizzi ancora il controllo dell'accesso basato sugli attributi, esamina prima i prerequisiti per l'utilizzo del controllo dell'accesso basato sui ruoli. Se hai eseguito l'upgrade del cluster da una versione precedente e utilizzi ABAC, devi aggiornare la configurazione dei controlli dell'accesso:

gcloud container clusters update CLUSTER_NAME \
    --no-enable-legacy-authorization

Per creare un nuovo cluster con il suggerimento riportato sopra:

gcloud container clusters create CLUSTER_NAME \
    --no-enable-legacy-authorization

Lascia abilitato il controller di ammissione DenyServiceExternalIPs

Non disattivare il controller di ammissione DenyServiceExternalIPs.

Il controller di ammissione DenyServiceExternalIPs impedisce ai servizi di utilizzare ExternalIP e mitiga una vulnerabilità di sicurezza nota.

Il controller di ammissione DenyServiceExternalIPs è abilitato per impostazione predefinita sui nuovi cluster creati su GKE 1.21 e versioni successive. Per i cluster che eseguono l'upgrade alle versioni GKE 1.21 e successive, puoi abilitare il controller di ammissione utilizzando questo comando:

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --no-enable-service-externalips

Passaggi successivi

• Scopri di più sulla sicurezza di GKE nella panoramica della sicurezza.
• Assicurati di comprendere il modello di responsabilità condivisa GKE.
• Scopri come applicare il benchmark CIS GKE al tuo cluster.
• Scopri di più sul controllo dell'accesso in GKE.
• Leggi la panoramica della rete GKE.
• Leggi la panoramica della multi-tenancy di GKE.