Esegui la migrazione da PodSecurityPolicy al controller di ammissione PodSecurity

Autopilot Standard

---

Questa pagina mostra come continuare a applicare molti controlli di sicurezza a livello di pod nei tuoi cluster Google Kubernetes Engine (GKE) eseguendo la migrazione da PodSecurityPolicy al controller di ammissione PodSecurity.

Panoramica

PodSecurityPolicy era un controller di ammissione Kubernetes che ti consentiva di applicare controlli di sicurezza a livello di pod, come gli standard di sicurezza dei pod di Kubernetes, fornendo un controllo granulare sulla configurazione di sicurezza dei carichi di lavoro di cui è stato eseguito il deployment. Il progetto Kubernetes ha ritirato PodSecurityPolicy e rimosso completamente la funzionalità in Kubernetes v1.25.

Se attualmente utilizzi PodSecurityPolicy nei tuoi cluster GKE, disabilita la funzionalità prima di eseguire l'upgrade a GKE versione 1.25 e successive.

Per saperne di più sul ritiro e sulla rimozione di PodSecurityPolicy, consulta la pagina Ritiro di PodSecurityPolicy.

PodSecurity e PodSecurityPolicy

Il controller di ammissione PodSecurity è disponibile e abilitato per impostazione predefinita sui cluster che eseguono le seguenti versioni di GKE:

• Versione 1.25 o successive: stabile
• Versione 1.23 e versione 1.24: beta

PodSecurity ti consente di applicare i criteri definiti negli standard di sicurezza dei pod ai carichi di lavoro di cui è stato eseguito il deployment. PodSecurity ti consente di continuare a implementare le configurazioni di sicurezza a livello di pod consigliate nei cluster dopo la migrazione da PodSecurityPolicy. A differenza di PodSecurityPolicy, PodSecurity non supporta configurazioni personalizzate.

Requisiti e limitazioni

• PodSecurity è disponibile in versione beta in GKE 1.23 e 1.24 e in versione stabile in GKE 1.25 e successive.
• PodSecurity non termina i pod già in esecuzione sui nodi, anche se violano il criterio applicato.
• PodSecurity non modifica i campi. Se utilizzi campi di mutazione in PodSecurityPolicy, modifica la specifica del pod per assicurarti che questi campi siano presenti quando esegui il deployment dei carichi di lavoro.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Attiva l'API Google Kubernetes Engine.
Attiva l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo gcloud components update.
  Nota:per le installazioni esistenti di gcloud CLI, assicurati di impostare la compute/region proprietà. Se utilizzi principalmente cluster zonali, imposta compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

• Assicurati di avere un cluster GKE Autopilot o Standard che esegue la versione 1.23 o successive.
  • Per i cluster Autopilot, registrati a un canale di rilascio in cui la versione predefinita è 1.23 o successive.
  • Per i cluster standard, registrati a un canale di rilascio o esegui l'upgrade del cluster a una versione specifica.
• Controlla le risorse PodSecurityPolicy per le configurazioni dei campi di modifica. Aggiungi questi campi ai manifest dei pod in modo che tutti i carichi di lavoro già in esecuzione sui nodi siano conformi a un criterio definito negli standard di sicurezza dei pod. Per istruzioni, consulta Semplificare e standardizzare le policy di sicurezza dei pod.

Configura il controller di ammissione PodSecurity nel tuo cluster.

Il controller di ammissione PodSecurity applica gli standard di sicurezza dei pod a livello di spazio dei nomi. Devi configurare il controller in modo che applichi uno dei criteri definiti dagli standard di sicurezza dei pod in ogni spazio dei nomi. Sono disponibili i seguenti criteri:

• Con limitazioni: la norma più restrittiva. È conforme alle best practice di hardening dei pod.
• Base: norma minimamente restrittiva che impedisce l'escalation dei privilegi noti. Consente tutti i valori predefiniti per i campi nelle specifiche dei pod.
• Privilegiato: criterio senza restrizioni che consente qualsiasi operazione, incluse le escalation dei privilegi note. Applica queste norme con cautela.

Per eseguire la migrazione della configurazione di PodSecurityPolicy al controller di ammissione PodSecurity, esegui le seguenti operazioni in ogni spazio dei nomi del cluster. Questi passaggi sono descritti in dettaglio nelle sezioni seguenti.

1. Applica il criterio Restricted in modalità dry-run allo spazio dei nomi e verifica la presenza di violazioni.
2. Se i tuoi pod violano il criterio Restricted, applica il criterio Baseline meno restrittivo in modalità dry-run allo spazio dei nomi e verifica la presenza di violazioni.
3. Se i tuoi pod violano le norme di base, modifica le specifiche dei pod per correggere le violazioni.
4. Quando il criterio Baseline non restituisce più violazioni, applica il criterio in modalità enforce allo spazio dei nomi.

Per evitare potenziali tempi di inattività se PodSecurity rifiuta nuovi pod, esegui questi passaggi in un ambiente di staging. In alternativa, puoi applicare il criterio identificato in modalità audit anziché in modalità enforce e rivedere gli audit log per trovare i pod potenzialmente rifiutati.

La modalità audit non applica le norme. GKE esegue il deployment dei pod e aggiunge voci agli audit log di GKE.

Elenca tutti gli spazi dei nomi nel cluster

Recupera un elenco di tutti gli spazi dei nomi nel cluster. Ripeti i passaggi nelle sezioni seguenti per ogni spazio dei nomi nell'elenco:

kubectl get ns

Nelle seguenti versioni di GKE, GKE ignora i criteri che applichi allo spazio dei nomi kube-system:

• 1.23.6-gke.1900 e versioni successive
• 1.24.0-gke.1200 e versioni successive

Nelle versioni precedenti di GKE, evita di applicare criteri in kube-system.

Applica ogni policy degli standard di sicurezza dei pod in modalità di prova

Nei passaggi seguenti, applicherai ogni norma in modalità dry-run, a partire dalla norma più restrittiva, ovvero Con restrizioni. Se l'output mostra un avviso, modifica la specifica del pod che viola la norma in modo che sia conforme alla norma oppure prova la norma di base meno restrittiva. Se l'output non mostra un avviso, puoi applicare la norma Baseline senza la modalità dry-run.

1. Applica il criterio Con restrizioni in modalità dry-run:

   kubectl label --dry-run=server --overwrite ns NAMESPACE \
       pod-security.kubernetes.io/enforce=restricted
   

   Se un pod nello spazio dei nomi viola il criterio Restricted, l'output è simile al seguente:

   Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "restricted:latest"
   namespace/NAMESPACE labeled
   

   Se le norme Con limitazioni mostrano un avviso, modifica i tuoi pod per correggere la violazione e riprova a eseguire il comando. In alternativa, prova la norma Baseline meno restrittiva nel passaggio successivo.

2. Applica il criterio Baseline in modalità dry-run:

   kubectl label --dry-run=server --overwrite ns NAMESPACE \
       pod-security.kubernetes.io/enforce=baseline
   

   Se un pod nello spazio dei nomi viola il criterio baseline, l'output è simile al seguente:

   Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "baseline:latest"
   namespace/NAMESPACE labeled
   

Se i tuoi pod violano la policy di base, modificali per correggere le violazioni e ripeti questo passaggio finché GKE non visualizza più un avviso.

Attenzione: puoi utilizzare facoltativamente il criterio con privilegi, che non prevede limitazioni. Prima di utilizzare il criterio con privilegi, assicurati di considerare attendibili tutti i carichi di lavoro e gli utenti che hanno accesso allo spazio dei nomi. Il criterio Privilegiato consente l'escalation dei privilegi noti, ma potrebbe essere necessario per determinati workload di sistema con privilegi.

Applicare la policy a uno spazio dei nomi

Quando identifichi la policy adatta a uno spazio dei nomi, applicala allo spazio dei nomi in modalità enforce:

kubectl label --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=POLICY

Sostituisci POLICY con il nome della norma, che può essere restricted, baseline o privileged.

Assicurati di ripetere i passaggi precedenti per ogni spazio dei nomi nel cluster.

Disabilita la funzionalità PodSecurityPolicy sul cluster

Dopo aver configurato il controller di ammissione PodSecurity per ogni spazio dei nomi nel cluster, disattiva la funzionalità PodSecurityPolicy:

gcloud beta container clusters update CLUSTER_NAME \
    --no-enable-pod-security-policy

Sostituisci CLUSTER_NAME con il nome del tuo cluster GKE.

Nota: dopo aver disattivato la funzionalità, non è necessario rimuovere manualmente gli eventuali oggetti PodSecurityPolicy rimanenti. Quando esegui kubectl get psp, GKE potrebbe mostrare le norme rimanenti, ma GKE non le applica.

Quando esegui l'upgrade del cluster alla versione 1.25 di GKE, GKE rimuove automaticamente tutti gli oggetti PodSecurityPolicy rimanenti, inclusi quelli aggiunti da GKE, Policy Controller e tutti gli oggetti PodSecurityPolicy che hai definito in precedenza.

Consigli

• Cerca di rispettare le norme con limitazioni, se possibile. Controlla le tue applicazioni per vedere se la configurazione può essere ulteriormente rafforzata.
• Puoi bloccare la modalità di sicurezza dei pod su una versione secondaria specifica di Kubernetes aggiungendo l'etichetta pod-security.kubernetes.io/MODE-version: VERSION ai comandi kubectl label nei passaggi precedenti. Sostituisci VERSION con il numero di versione di Kubernetes, ad esempio v1.24.
• Dopo aver disattivato la funzionalità PodSecurityPolicy, esamina le applicazioni in esecuzione per verificare la presenza di interruzioni o lacune nella configurazione di sicurezza.
• Dopo aver configurato PodSecurity, aggiorna la procedura di creazione dello spazio dei nomi per applicare automaticamente un'etichetta PodSecurity a tutti i nuovi spazi dei nomi. Per informazioni, consulta Esaminare la procedura di creazione dello spazio dei nomi.

Passaggi successivi

• Scopri di più sugli standard di sicurezza dei pod.
• Scopri di più sul PodSecurity admission controller.
• Scopri come applicare criteri di sicurezza personalizzati a livello di pod utilizzando Gatekeeper.
• Scopri di più sul ritiro di PodSecurityPolicy.