Migrazione da PodSecurityPolicy al controller di ammissione PodSecurity

Autopilota Standard

---

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

Panoramica

PodSecurityPolicy era un controller di ammissione Kubernetes che consente di Controlli di sicurezza a livello di pod, come gli standard di sicurezza dei pod di Kubernetes, fornendo un controllo granulare sulla configurazione della sicurezza carichi di lavoro con scale out impegnativi. Il progetto Kubernetes ha deprecato PodSecurityPolicy e ha rimosso la classe completamente in Kubernetes v1.25.

Se al momento utilizzi PodSecurityPolicy nei tuoi cluster GKE, disabilita la funzionalità prima di eseguire l'upgrade a GKE versione 1.25 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 su che eseguono le seguenti versioni GKE:

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

PodSecurity ti consente di applicare i criteri definiti nel Standard di sicurezza dei pod sui carichi di lavoro di cui hai 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 cambia 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.
Abilita l'API Google Kubernetes Engine
• Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi inizializzare con 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, registrarsi 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 qualsiasi carico di lavoro già in esecuzione sui nodi sono conformi a un criterio definito negli standard di sicurezza dei pod. Per 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 in a livello dello 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. Le seguenti criteri sono disponibili:

• Con restrizioni: norma più restrittiva. Conforme al meglio per la protezione dei pod pratiche.
• Base di riferimento: criterio minimamente restrittivo che impedisce il privilegio noto e riassegnazioni. Consente tutti i valori predefiniti per i campi nelle specifiche del pod.
• Con privilegi: criterio senza restrizioni che consente qualsiasi elemento, inclusi i dati e l'escalation dei privilegi. Applica questa norma con cautela.

Per eseguire la migrazione della configurazione PodSecurityPolicy all'ammissione PodSecurity esegui la seguente operazione 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 pod violano il criterio Con restrizioni, applica il criterio meno restrittivo. Il criterio Baseline in modalità dry-run rimanda allo spazio dei nomi e verifica se violazioni delle norme.
3. Se i tuoi pod violano le norme relative al valore di riferimento, modifica le relative specifiche per risolvere le violazioni.
4. Se il criterio Base di riferimento non restituisce più violazioni, applica la classe in modalità enforce allo spazio dei nomi.

Per evitare potenziali tempi di riposo se PodSecurity rifiuta i nuovi pod, svolgi questi passaggi in un ambiente di staging. In alternativa, puoi applicare lo strumento in modalità audit anziché in modalità enforce ed esamina i log di controllo per e trovare potenziali pod rifiutati.

La modalità audit non applica il criterio. Deployment di GKE i pod e aggiunge voci agli audit log di GKE.

Elenca tutti gli spazi dei nomi nel cluster

Ottieni un elenco di tutti gli spazi dei nomi nel tuo cluster. Ripeti i passaggi nelle seguenti sezioni 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 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 Limitato 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 viene simile al seguente:

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

   Se il criterio Limitato mostra un avviso, modifica i pod per correggere la violazione e riprova a eseguire il comando. In alternativa, prova con meno il criterio Baseline restrittivo 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 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 identifichi il criterio che funziona per uno spazio dei nomi, applicalo 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 nel tuo cluster.

Disattiva la funzionalità PodSecurityPolicy nel cluster

Dopo aver configurato il controller di ammissione PodSecurity per ogni nello spazio dei nomi del tuo cluster, disabilita PodSecurityPolicy funzionalità:

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 oggetti PodSecurityPolicy rimanenti. Quando esegui kubectl get psp, GKE potrebbe visualizzare i criteri rimanenti, ma non li applica.

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

Consigli

• Se possibile, cerca di rispettare le norme relative alle limitazioni. Controlla le applicazioni per verificare se la configurazione può essere ulteriormente rafforzata.
• Puoi bloccare la modalità di sicurezza dei pod a una versione secondaria di Kubernetes specifica aggiungendo l'etichetta pod-security.kubernetes.io/MODE-version: VERSION ai comandi kubectl label nella passaggi precedenti. Sostituisci VERSION con il numero della versione di Kubernetes, ad esempio v1.24.
• Dopo aver disabilitato la funzionalità PodSecurityPolicy, controlla l'esecuzione applicazioni 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 controller di ammissione.
• Scopri come applicare criteri di sicurezza personalizzati a livello di pod utilizzando Gatekeeper.
• Scopri di più sul ritiro di PodSecurityPolicy.