Rafforza la sicurezza del cluster

Questa pagina descrive la procedura per implementare le best practice attuali per il rafforzamento del cluster Google Kubernetes Engine (GKE). Questa guida dà la priorità alle mitigazioni di sicurezza di alto valore che richiedono un intervento del cliente al momento della creazione del cluster. Le funzionalità meno critiche, le impostazioni predefinite sicure e quelle che possono essere attivate dopo la creazione sono menzionate più avanti nel documento.

Questo documento è rivolto a specialisti della sicurezza che definiscono, gestiscono e implementano criteri e procedure per proteggere i dati di un'organizzazione da accessi non autorizzati. Per scoprire di più sui ruoli comuni e sugli esempi di attività a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Prima di leggere questa pagina, assicurati di conoscere quanto segue:

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

Se crei nuovi cluster in GKE, molte di queste protezioni sono attive per impostazione predefinita. Se stai eseguendo l'upgrade di cluster esistenti, assicurati di esaminare regolarmente questa guida all'hardening e di attivare le nuove funzionalità.

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

Molti di questi consigli, oltre ad altre configurazioni errate comuni, possono essere controllati automaticamente utilizzando Security Health Analytics.

Esegui l'upgrade dell'infrastruttura GKE in modo tempestivo

Consiglio del benchmark GKE CIS: 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.

Per informazioni sulle patch di sicurezza, consulta i bollettini sulla sicurezza di GKE.

In Google Kubernetes Engine, i piani di controllo vengono sottoposti a patch e upgrade automaticamente. L'upgrade automatico dei nodi consente inoltre di eseguire l'upgrade automatico dei nodi del cluster.

L'upgrade automatico dei nodi è abilitato per impostazione predefinita per i cluster creati utilizzando la console Google Cloud da giugno 2019 e per i cluster creati utilizzando l'API dall'11 novembre 2019.

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

Per scoprire di più, consulta Upgrade automatico dei nodi.

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

Consigli del benchmark GKE CIS: 6.6.2. Preferisci i cluster VPC nativi, 6.6.3. Assicurati che l'opzione Reti autorizzate sia abilitata, 6.6.4. Assicurati che i cluster vengano creati con l'endpoint privato abilitato e l'accesso pubblico disabilitato e con la versione 6.6.5. Assicurati che i cluster vengano creati con i nodi privati

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

Limita 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 a tua disposizione per la protezione a livello di rete:

• Endpoint basato su DNS abilitato (opzione consigliata): puoi controllare chi può accedere all'endpoint basato su DNS con Controlli di servizio VPC. Controlli di servizio VPC ti consente di definire un parametro di sicurezza per tutte le API Google nel tuo progetto con attributi sensibili al contesto come l'origine della 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 esterni e interni basati su IP disabilitato:impedisce tutto l'accesso al piano di controllo tramite endpoint basati su IP.

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

• Accesso all'endpoint basato su IP esterno abilitato, reti autorizzate attivate: questa opzione fornisce accesso limitato al piano di controllo dagli indirizzi IP di origine che definisci. Questa è una buona scelta se non hai un'infrastruttura VPN esistente o se hai utenti remoti o sedi distaccate 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:consente a chiunque su internet di effettuare connessioni di rete al control plane.

Se utilizzi endpoint basati su IP, consigliamo ai cluster di utilizzare reti autorizzate.

In questo modo, il piano di controllo è raggiungibile da:

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

Limita l'accesso ai nodi

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

Questo indica a GKE di eseguire il provisioning dei nodi con indirizzi IP interni, il che significa che i nodi non sono direttamente raggiungibili tramite la rete internet pubblica.

Utilizza regole firewall con i privilegi minimi

Riduci al minimo il rischio di accessi indesiderati utilizzando il principio del privilegio minimo per le regole firewall

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

GKE crea queste regole firewall predefinite con una priorità di 1000. Se crei regole firewall permissive con una priorità più elevata, ad esempio una regola firewall allow-all per il debugging, il tuo cluster è a rischio di accessi indesiderati.

Autenticazione di gruppo

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

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

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

Per istruzioni su come attivare Google Gruppi per RBAC, consulta Google Gruppi per RBAC.

Scelte per i nodi del contenitore

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

Abilita Shielded GKE Nodes

Consiglio del benchmark GKE CIS: 6.5.5. Assicurati che i nodi GKE schermati siano abilitati

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. I nodi GKE schermati devono essere abilitati 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 attivare Shielded GKE Nodes e come attivare l'avvio protetto con Shielded GKE Nodes, consulta Utilizzare Shielded GKE Nodes.

Scegli un'immagine del nodo rafforzata con il runtime containerd

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

containerd è il componente di runtime di base di Docker ed è stato progettato per fornire funzionalità di base dei container per l'interfaccia CRI (Container Runtime Interface) di Kubernetes. È molto meno complesso del daemon Docker completo e, di conseguenza, 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 rafforzata appositamente per l'esecuzione di container.

Abilita Workload Identity Federation per GKE

Consiglio del benchmark CIS GKE: 6.2.2. Preferisci utilizzare account di servizio Google Cloud e Workload Identity dedicati

Workload Identity Federation for GKE è il metodo consigliato per eseguire l'autenticazione alle API Google Cloud.

Workload Identity Federation for GKE elimina 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 dalla federazione delle identità per i carichi di lavoro per GKE.

Protezione dell'isolamento del carico di lavoro con GKE Sandbox

Consiglio del benchmark CIS GKE: 6.10.4. Valuta la possibilità di utilizzare GKE Sandbox per rafforzare l'isolamento dei carichi di lavoro, in particolare per quelli non attendibili

GKE Sandbox fornisce un ulteriore livello di sicurezza per impedire al codice dannoso di influire sul kernel host dei nodi del cluster.

Puoi eseguire i container in un ambiente sandbox per proteggerti dalla 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 di sicurezza. Questo tipo di attacco consente a un malintenzionato di accedere alla VM host del contenitore e quindi ad altri contenitori sulla stessa VM. Una sandbox come GKE Sandbox può contribuire a limitare l'impatto di questi attacchi.

Ti consigliamo di eseguire la sandbox di un carico di lavoro in situazioni come:

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

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 agli 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 dei bollettini sulla sicurezza tramite le notifiche dei cluster GKE, consulta Notifiche cluster.

Disattiva la porta di sola lettura non sicura di Kubelet

Disattiva la porta di sola lettura di kubelet e imposta tutti i workload che utilizzano la porta10255 in modo che utilizzino invece la porta più sicura 10250.

Il processo kubelet in esecuzione sui nodi fornisce 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 10250 più sicura.

Per le istruzioni, consulta Disattivare la porta di sola lettura di kubelet nei cluster GKE.

Autorizzazioni

Utilizza gli account di servizio IAM con privilegio minimo

Consiglio del benchmark GKE CIS: 6.2.1. È preferibile non eseguire i cluster GKE utilizzando l'account di servizio predefinito di Compute Engine

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

Se utilizzi l'account di servizio predefinito di Compute Engine per altre funzioni nel progetto o nell'organizzazione, l'account di servizio potrebbe avere più autorizzazioni di quelle necessarie per GKE, il che potrebbe esporre a rischi per la sicurezza.

L'account di servizio collegato ai nodi deve essere utilizzato solo dai carichi di lavoro di sistema che svolgono 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:

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

Concedi l'accesso ai repository di immagini privati

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

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:

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 possa creare nuovi cluster o pool di nodi con questo account di servizio, devi concedergli il ruolo Utente account di servizio su 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 nuovo account di servizio. Per i cluster Autopilot, devi creare un nuovo cluster con l'account di servizio. Per le istruzioni, consulta Creare 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 vuoi che il tuo cluster GKE abbia accesso ad altri servizi Google Cloud, devi utilizzare la federazione delle identità per i carichi di lavoro per GKE.

Limita l'accesso al rilevamento delle API del cluster

Per impostazione predefinita, Kubernetes esegue il bootstrap dei cluster con un insieme permissivo di ClusterRoleBindings di rilevamento che forniscono accesso ampio 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 significativo di sicurezza per i cluster su GKE. Per ulteriori informazioni, consulta Evitare ruoli e gruppi predefiniti.

Chi vuole rafforzare le API di rilevamento del proprio cluster dovrebbe considerare 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 GKE, devi trattare tutte le informazioni di rilevamento delle API (ovvero lo schema di CustomResource, 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 del benchmark GKE CIS: 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 e etichette appropriate a ogni spazio dei nomi per responsabilità e ricarica. Concedi agli sviluppatori solo il livello di accesso al loro spazio dei nomi di cui hanno bisogno per eseguire il deployment e gestire la loro applicazione, in particolare in produzione. Mappa le attività che i tuoi utenti devono svolgere sul cluster e definisci le autorizzazioni di cui hanno bisogno per svolgere ogni attività.

Per ulteriori informazioni sulla creazione degli 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) lavorano insieme e un'entità deve disporre di autorizzazioni sufficienti a entrambi i livelli per lavorare con le risorse del 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 un criterio di rete

Consiglio del benchmark GKE CIS: 6.6.7. Assicurati che il criterio di rete sia abilitato e impostato come appropriato

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

La limitazione dell'accesso di rete ai servizi rende molto più difficile per gli aggressori muoversi lateralmente all'interno del cluster e offre inoltre ai servizi una certa protezione contro i denial of service accidentali o deliberati. Ecco due modi consigliati per controllare il traffico:

1. Utilizza Istio. Consulta Installazione di Istio su Google Kubernetes Engine se ti interessano il bilanciamento del carico, l'autorizzazione dei servizi, il throttling, la quota, le metriche e altro ancora.
2. Utilizza i criteri di rete di Kubernetes. Consulta Creare un criterio di rete del 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 contiene un eccellente 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.

Se necessario, Istio e le norme di rete possono essere utilizzati insieme.

Gestione di secret

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

Devi fornire un ulteriore livello di protezione per i dati sensibili, come i secret, archiviati in etcd. Per farlo, devi configurare un gestore dei secret integrato con i cluster GKE. Alcune soluzioni funzionano sia in GKE sia in Google Distributed Cloud e potrebbero essere più adatte se esegui carichi di lavoro in più ambienti. Se scegli di utilizzare un gestore dei segreti esterno come HashiCorp Vault, devi configurarlo prima di creare il cluster.

Hai a disposizione diverse opzioni per la gestione dei secret.

• Puoi utilizzare i secret di Kubernetes in modo nativo in GKE. Se vuoi, puoi criptarli a livello di applicazione con una chiave che gestisci utilizzando la crittografia dei secret a livello di applicazione.
• Puoi utilizzare un gestore dei secret come HashiCorp Vault. Se eseguito in una modalità HA rafforzata, questo approccio fornirà un modo coerente e pronto per la produzione per gestire i secret. Puoi eseguire l'autenticazione in HashiCorp Vault utilizzando un account di servizio Kubernetes o un account di servizio Google Cloud. Per scoprire di più sull'utilizzo di GKE con Vault, consulta Eseguire e connettersi ad HashiCorp Vault su Kubernetes.

Le VM GKE sono criptate a livello di archiviazione per impostazione predefinita, incluso etcd.

Utilizzare i controller di ammissione per applicare i criteri

I controller di ammissione sono plug-in che regolano e applicano il modo in cui viene utilizzato il cluster. Devono essere attivati per poter utilizzare alcune delle funzionalità di sicurezza più avanzate di Kubernetes e rappresentano un elemento importante dell'approccio di difesa in profondità per il rafforzamento del cluster.

Per impostazione predefinita, i pod in Kubernetes possono operare con funzionalità superiori a quelle di cui hanno bisogno. Devi limitare le funzionalità del pod solo a quelle richieste per quel 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 verificare la sicurezza su larga scala nei cluster GKE utilizzando criteri dichiarativi. Per scoprire come utilizzare Policy Controller per applicare i 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 capacità dei carichi di lavoro di automodificarsi

Alcuni carichi di lavoro Kubernetes, in particolare quelli di sistema, hanno l'autorizzazione per automodificarsi. Ad esempio, alcuni carichi di lavoro eseguono la scalabilità automatica verticale. Sebbene sia comodo, questo può consentire a un malintenzionato che ha già compromesso un nodo di eseguire un'ulteriore riassegnazione nel cluster. Ad esempio, un malintenzionato potrebbe modificare un carico di lavoro sul nodo in modo che venga eseguito come account di servizio con privilegi maggiori esistente nello stesso spazio dei nomi.

Idealmente, ai workload non dovrebbe essere concessa l'autorizzazione per modificarsi. Quando è necessaria l'automodifica, puoi limitare le autorizzazioni applicando vincoli di Gatekeeper o Policy Controller, ad esempio NoUpdateServiceAccount dalla libreria open source Gatekeeper, che fornisce diversi criteri di sicurezza utili.

Quando esegui il deployment dei criteri, in genere è necessario consentire ai controller che gestiscono il ciclo di vita del cluster di aggirarli. Questo è necessario affinché i controller possano apportare modifiche al cluster, ad esempio applicare upgrade. 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 deprecato

Il tipo di volume gcePersistentDisk deprecato consente di montare un disco permanente di Compute Engine ai pod. Ti consigliamo di limitare l'utilizzo del gcePersistentDisk tipo di volume nei tuoi carichi di lavoro. GKE non esegue controlli di autorizzazione IAM sul pod durante il montaggio di questo tipo di volume, anche se Google Cloud esegue controlli di autorizzazione quando colleghi il disco alla VM di base. 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 e utilizzare i dischi permanenti di Compute Engine, utilizza invece gli oggetti PersistentVolumes e PersistentVolumeClaim. Applica nel cluster criteri di sicurezza 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 una limitazione personalizzata 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 cluster.

   Policy Controller è una funzionalità a pagamento per gli utenti GKE. Policy Controller si basa su Gatekeeper open source, ma offre anche accesso alla libreria completa dei modelli di vincolo, ai bundle di criteri e all'integrazione con le dashboard della console Google Cloud per aiutarti a osservare e gestire i tuoi cluster. I bundle di criteri sono best practice opinative 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 file manifest gatekeeper.yaml Gatekeeper in un editor di testo. Modifica il campo rules nella specifica MutatingWebhookConfiguration per sostituire i caratteri jolly (*) con gruppi di 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 tuo cluster Autopilot per installare Gatekeeper. Questo è necessario perché, come misura di sicurezza integrata, Autopilot non consente i caratteri jolly nei webhook di ammissione con mutazioni.

2. Esegui il deployment del modello di vincolo 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 dei cluster per rilevare eventuali deviazioni dalle impostazioni definite.

Molti dei consigli descritti in questa guida all'hardening, nonché altre configurazioni errate comuni, possono essere controllati automaticamente utilizzando Security Health Analytics.

Valori predefiniti sicuri

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

Proteggere i metadati del nodo

Consigli del benchmark CIS GKE: 6.4.1. Assicurati che le API per i metadati delle istanze Compute Engine legacy siano disabilitate e 6.4.2. Assicurati che il server metadati GKE sia abilitato

Gli endpoint del server di metadati di Compute Engine v0.1 e v1beta1 sono stati ritirati e disattivati il 30 settembre 2020. Questi endpoint non applicavano le intestazioni di query dei metadati. Per la pianificazione dell'interruzione, consulta la sezione Deprecation 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 Workload Identity Federation per GKE o Metadata Concealment.

Lasciare disattivati i metodi di autenticazione client precedenti

Consigli del benchmark GKE CIS: 6.8.1. Assicurati che l'autenticazione di base tramite password statiche sia disabilitata e che sia installata la versione 6.8.2. Assicurati che l'autenticazione tramite certificati client sia disabilitata

Esistono diversi metodi di autenticazione nel server dell'API Kubernetes. In GKE, i metodi supportati sono i token bearer dell'account di servizio, i token OAuth e i certificati client x509. GKE gestisce l'autenticazione con gcloud utilizzando il metodo del token OAuth, configurando la configurazione di Kubernetes, ottenendo un token di accesso e mantenendolo aggiornato.

Prima dell'integrazione di GKE con OAuth, un certificato x509 generato una sola volta o una password statica erano gli unici metodi di autenticazione disponibili, ma ora non sono consigliati e devono essere disattivati. Questi metodi rappresentano una superficie di attacco più ampia per la compromissione del cluster e sono stati disattivati per impostazione predefinita 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 dalla versione 1.19 di GKE.

I cluster esistenti devono passare a OAuth. Se un sistema esterno al cluster richiede una credenziale a lungo termine, 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.

Attualmente, non è possibile rimuovere il certificato client precaricato da un cluster esistente, ma non ha autorizzazioni se RBAC è abilitato e ABAC è disabilitato.

Lascia Cloud Logging abilitato

Consiglio del benchmark GKE CIS: 6.7.1. Assicurati che Logging e Monitoring di Kubernetes di Stackdriver siano abilitati

Per ridurre i costi operativi e mantenere una visione consolidata dei log, implementa una strategia di logging coerente ovunque siano eseguiti i deployment dei cluster. I cluster GKE Enterprise sono integrati con Cloud Logging per impostazione predefinita e questa impostazione dovrebbe rimanere configurata.

In tutti i cluster GKE è abilitato per impostazione predefinita il logging di controllo Kubernetes, che mantiene 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.

I cluster GKE integrano il logging di controllo di Kubernetes 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 del benchmark CIS GKE: 6.10.1. Assicurati che la UI web di Kubernetes sia disabilitata

Non devi attivare l'interfaccia utente web di Kubernetes (Dashboard) quando esegui l'applicazione su GKE.

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

Per disattivare l'interfaccia utente web di Kubernetes:

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

Lasciare ABAC disattivato

Consiglio per il benchmark GKE CIS: 6.8.4. Assicurati che l'autorizzazione legacy (ABAC) sia disabilitata

Devi disabilitare il controllo dell'accesso basato su attributi (ABAC) e utilizzare 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. Il RBAC consente di definire i ruoli con regole contenenti un insieme di autorizzazioni. RBAC offre notevoli vantaggi in termini di sicurezza rispetto ad ABAC.

Se continui a utilizzare l'accesso basato su attributi, consulta prima i prerequisiti per l'utilizzo del RBAC. Se hai eseguito l'upgrade del cluster da una versione precedente e utilizzi ABAC, devi aggiornare la configurazione dei controlli di accesso:

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

Per creare un nuovo cluster con il consiglio riportato sopra:

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

Lasciare attivo il controller di ammissione DenyServiceExternalIPs

Non disattivare il controller di ammissione DenyServiceExternalIPs.

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

Il controller di ammissione DenyServiceExternalIPs è abilitato per impostazione predefinita nei nuovi cluster creati su GKE 1.21 e versioni successive. Per i cluster sottoposti ad upgrade alle versioni GKE 1.21 e successive, puoi abilitare il controller di ammissione utilizzando il seguente 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 del multitenancy di GKE.