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 consente di applicare controlli di sicurezza a livello di pod come gli standard di sicurezza dei pod Kubernetes, fornendo un controllo granulare sulla configurazione di sicurezza dei carichi di lavoro di cui hai eseguito il deployment. Il progetto Kubernetes ha deprecato PodSecurityPolicy e rimosso la funzionalità completamente 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 la rimozione di PodSecurityPolicy, consulta 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 consente di applicare in modo forzato i criteri definiti negli standard di sicurezza dei pod sui carichi di lavoro di cui hai eseguito il deployment. PodSecurity 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 in GKE 1.23 e 1.24 e in versione stabile in GKE versione 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 mutanti in PodSecurityPolicy, modifica le specifiche del pod per assicurarti che siano presenti quando esegui il deployment dei carichi di lavoro.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

Abilita l'API Google Kubernetes Engine.

Abilita l'API Google Kubernetes Engine

Se vuoi utilizzare Google Cloud CLI per questa attività, installa e initialize gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.
Nota: per le installazioni esistenti dell'interfaccia a riga di comando gcloud, assicurati di impostare le proprietà compute/region e compute/zone. Impostando le località predefinite, puoi evitare errori nellgcloud CLI come segue: 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 in un canale di rilascio in cui la versione predefinita è 1.23 o successive.
- Per i cluster Standard, registrati in un canale di rilascio o esegui l'upgrade del cluster a una versione specifica.
Controlla le tue risorse PodSecurityPolicy per le configurazioni dei campi mutanti. Aggiungi questi campi ai manifest dei pod in modo che tutti i carichi di lavoro 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 tuo cluster

Il controller di ammissione PodSecurity applica gli standard di sicurezza dei pod a livello dei nomi. Devi configurare il controller per 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 di protezione dei pod.
Base di riferimento: norme minimamente restrittive che impediscono le escalation dei privilegi note. Consente tutti i valori predefiniti per i campi nelle specifiche del pod.
Con privilegi: criterio senza restrizioni che consente qualsiasi cosa, incluse le escalation dei privilegi note. Applica questo criterio con cautela.

Per eseguire la migrazione della configurazione PodSecurityPolicy al controller di ammissione PodSecurity, procedi nel seguente modo in ogni spazio dei nomi nel tuo cluster. Questi passaggi sono descritti dettagliatamente nelle sezioni seguenti.

Applica il criterio Con restrizioni in modalità dry-run allo spazio dei nomi e verifica la presenza di violazioni.
Se i tuoi pod violano il criterio Con restrizioni, applica allo spazio dei nomi il criterio Base di riferimento meno restrittivo in modalità dry-run e verifica la presenza di eventuali violazioni.
Se i tuoi pod violano il criterio Base di riferimento, modifica le specifiche dei pod per correggere le violazioni.
Quando il criterio Base di riferimento 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 gestione temporanea. In alternativa, puoi applicare il criterio identificato in modalità audit anziché in modalità enforce ed esaminare gli audit log per trovare potenziali pod rifiutati.

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

Elenca tutti gli spazi dei nomi nel tuo 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 in kube-system.

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

Nei passaggi seguenti, applicherai ogni criterio in modalità dry-run, iniziando con il criterio Con limitazioni più restrittivo. Se l'output mostra un avviso, modifica la specifica del pod in violazione per renderla conforme al criterio o prova il criterio Base di riferimento meno restrittivo. Se l'output non mostra alcun avviso, puoi applicare il criterio Base di riferimento senza la modalità dry-run.

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 Limitato mostra un avviso, modifica i pod per correggere la violazione e riprova a utilizzare il comando. In alternativa, prova il criterio Base di riferimento meno restrittivo nel passaggio seguente.

Applica il criterio Base di riferimento 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.

Applica il criterio a uno spazio dei nomi

Quando identifichi 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 restricted, baseline o privileged.

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

Disabilita la funzionalità PodSecurityPolicy sul tuo cluster

Dopo aver configurato il controller di ammissione PodSecurity per ogni spazio dei nomi nel cluster, disabilita 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.

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 qualsiasi oggetto PodSecurityPolicy definito in precedenza.

Suggerimenti

Se possibile, cerca di rispettare le norme sulle limitazioni. Controlla le tue applicazioni per verificare se la configurazione può essere protetta ulteriormente.
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 nei passaggi precedenti. Sostituisci VERSION con il numero di versione di Kubernetes, ad esempio v1.24.
Dopo aver disabilitato la funzionalità PodSecurityPolicy, esamina le applicazioni in esecuzione per verificare l'eventuale presenza di interruzioni o lacune nella configurazione di sicurezza.
Dopo aver configurato PodSecurity, aggiorna il processo di creazione dello spazio dei nomi per applicare automaticamente un'etichetta PodSecurity a tutti i nuovi spazi dei nomi. Per informazioni, consulta Esaminare il processo di creazione dello spazio dei nomi.