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 deprecato PodSecurityPolicy e ha rimosso completamente la funzionalità nella versione 1.25 di Kubernetes.

Se al momento utilizzi PodSecurityPolicy nei tuoi cluster GKE, disabilita la funzionalità prima di eseguire l'upgrade alla versione 1.25 di GKE e versioni successive.

Per scoprire di più sul ritiro e sulla rimozione di PodSecurityPolicy, consulta Ritiro di PodSecurityPolicy.

PodSecurity e PodSecurityPolicy

Il controller di ammissione PodSecurity è disponibile e abilitato per impostazione predefinita nei 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 tuoi carichi di lavoro di cui è stato eseguito il deployment. PodSecurity ti consente di continuare a implementare le configurazioni di sicurezza consigliate a livello di pod nei tuoi cluster dopo la migrazione da PodSecurityPolicy. A differenza di PodSecurityPolicy, PodSecurity non supporta le configurazioni personalizzate.

Requisiti e limitazioni

• PodSecurity è disponibile in versione beta nelle versioni GKE 1.23 e 1.24 e in versione stabile nelle versioni GKE 1.25 e successive.
• PodSecurity non termina i pod già in esecuzione sui tuoi nodi, anche se violano il criterio applicato.
• PodSecurity non modifica i campi. Se utilizzi campi con mutazioni in PodSecurityPolicy, modifica la specifica del pod per assicurarti che questi campi siano presenti al momento del 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à, installa e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, ottieni la versione più recente eseguendo gcloud components update.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare le proprietà compute/region e compute/zone. Se imposti le posizioni predefinite, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location.

• 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 successiva.
  • 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 verificare la presenza di configurazioni di campi con mutazioni. Aggiungi questi campi ai manifest dei pod in modo che tutti i workload già in esecuzione sui tuoi nodi siano conformi a un criterio definito negli standard di sicurezza dei pod. Per le istruzioni, consulta Semplificare e standardizzare i criteri di sicurezza dei pod.

Configura il controller di ammissione PodSecurity nel 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 da applicare uno dei criteri definiti dagli standard di sicurezza dei pod in ogni spazio dei nomi. Sono disponibili i seguenti criteri:

• Con restrizioni: norma più restrittiva. È conforme alle best practice per il rafforzamento dei pod.
• Valore di base: criterio minimamente restrittivo che impedisce le riassegnazioni di privilegi note. Consente tutti i valori predefiniti per i campi nelle specifiche del pod.
• Con privilegi: criterio senza restrizioni che consente qualsiasi operazione, incluse le riassegnazioni di privilegi note. Applica queste norme con cautela.

Per eseguire la migrazione della configurazione di PodSecurityPolicy al controller di ammissione PodSecurity, segui questa procedura in ogni spazio dei nomi del cluster. Questi passaggi sono descritti in dettaglio nelle sezioni che seguono.

1. Applica il criterio Con restrizioni in modalità dry-run allo spazio dei nomi e controlla la presenza di violazioni.
2. Se i tuoi pod violano il criterio Con restrizioni, applica al tuo spazio dei nomi il criterio meno restrittivo Base in modalità dry-run e controlla se ci sono violazioni.
3. Se i tuoi pod violano le norme relative al valore di riferimento, modifica le relative specifiche per risolvere le violazioni.
4. Quando il criterio Baseline non restituisce più violazioni, applica il criterio allo spazio dei nomi in modalità enforce.

Per evitare potenziali tempi di riposo se PodSecurity rifiuta i nuovi pod, svolgi questi passaggi in un ambiente di staging. In alternativa, puoi applicare il criterio identificato in modalità audit anziché enforce e esaminare i log di controllo per trovare potenziali pod 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

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

kubectl get ns

Nelle seguenti versioni di GKE, GKE ignora le norme 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 i criteri in kube-system.

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

Nei passaggi che seguono, dovrai applicare ogni norma in modalità dry-run, iniziando dalla norma Con restrizioni più restrittiva. Se l'output mostra un avviso, modifica la specifica del pod in violazione in modo da rispettare le norme o prova le norme di riferimento meno restrittive. Se l'output non mostra un avviso, puoi poi applicare il criterio Base 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 il criterio Con restrizioni mostra un avviso, modifica i pod per correggere la violazione e riprova a eseguire il comando. In alternativa, prova il criterio Base meno restrittivo nel passaggio successivo.

2. Applica il criterio Base 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 pod violano il criterio di riferimento, modificali per correggere le violazioni e ripeti questo passaggio finché GKE non mostra più un avviso.

Attenzione: se vuoi, puoi utilizzare il criterio Privilegio, che non prevede limitazioni. Prima di utilizzare il criterio Privileged, assicurati di considerare attendibili tutti i carichi di lavoro e gli utenti che hanno accesso allo spazio dei nomi. Il criterio Privileged consente le riassegnazioni di privilegi note, ma potrebbe essere necessario per determinati carichi di lavoro del sistema con privilegi.

Applicare il criterio a uno spazio dei nomi

Quando hai identificato il criterio che funziona per uno spazio dei nomi, applicalo allo spazio dei nomi in modalità enforce:

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

Sostituisci POLICY con il nome del criterio, che può essere uno di restricted, baseline o privileged.

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

Disattiva la funzionalità PodSecurityPolicy nel 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 cluster GKE.

Nota: dopo aver disattivato la funzionalità, non è necessario rimuovere manualmente gli oggetti PodSecurityPolicy rimanenti. Quando esegui kubectl get psp, GKE potrebbe mostrare i criteri rimanenti, ma non li 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, da Policy Controller e da eventuali oggetti PodSecurityPolicy definiti in precedenza.

Consigli

• Cerca di rispettare le norme relative ai contenuti con limitazioni, se possibile. Controlla le applicazioni per verificare se la configurazione può essere ulteriormente rafforzata.
• Puoi bloccare la modalità di sicurezza dei pod su una versione minore 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 della versione di Kubernetes, ad esempio v1.24.
• Dopo aver disattivato la funzionalità PodSecurityPolicy, controlla le applicazioni in esecuzione per verificare la presenza di interruzioni o lacune nella configurazione della 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 controller di ammissione.
• Scopri come applicare criteri di sicurezza personalizzati a livello di pod utilizzando Gatekeeper.
• Scopri di più sul ritiro di PodSecurityPolicy.