Questa pagina è stata tradotta dall'API Cloud Translation.

Migrazione da PodSecurityPolicy al controller di ammissione PodSecurity

Autopilot 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 alla 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 attualmente utilizzi PodSecurityPolicy nei tuoi cluster GKE, disabilita la funzionalità prima di eseguire l'upgrade a GKE versione 1.25 e in un secondo momento.

Per saperne di più sul ritiro e la rimozione di PodSecurityPolicy, fai riferimento al 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 configurazioni di sicurezza a livello di pod consigliate nei tuoi cluster dopo la migrazione da PodSecurityPolicy. A differenza di PodSecurityPolicy, PodSecurity non supporta configurazioni personalizzate.

Requisiti e limitazioni

PodSecurity è disponibile in versione beta nelle versioni GKE 1.23 e 1.24 ed in stabile in GKE 1.25 e versioni successive.
PodSecurity non termina i pod già in esecuzione sui tuoi nodi, anche se violano la norma applicata.
PodSecurity non cambia i campi. Se utilizzi una qualsiasi campi mutanti in PodSecurityPolicy, modificare le specifiche del pod per assicurarti che questi campi siano presenti al momento del deployment per gestire i carichi di lavoro.

Prima di iniziare

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

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, scarica la versione più recente eseguendo gcloud components update.
Nota: per gcloud CLI esistente di installazione, assicurati di impostare compute/region e compute/zone proprietà. Se imposti località predefinite, puoi evitare errori in gcloud CLI come i seguenti: One of [--zone, --region] must be supplied: Please specify location.

Assicurati di avere un cluster GKE Autopilot Cluster standard con 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, iscriviti a un canale di rilascio oppure eseguire l'upgrade del cluster a una versione specifica.
Controlla le configurazioni dei campi che variano nelle risorse PodSecurityPolicy. 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 tuo cluster

Il controller di ammissione PodSecurity applica gli standard di sicurezza dei pod in a livello dello spazio dei nomi. Devi configurare il controller affinché applichi uno dei criteri definiti dagli standard di sicurezza dei pod in ogni spazio dei nomi. Le seguenti criteri sono disponibili:

Con limitazioni: 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 dei 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 dettagliatamente nelle sezioni che seguono.

Applica il criterio Limitato in modalità dry-run allo spazio dei nomi e controlla per violazioni.
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.
Se i tuoi pod violano il criterio Baseline, modifica le specifiche dei pod in correggere le violazioni.
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 inattività se PodSecurity rifiuta nuovi pod, esegui queste operazioni passaggi in un ambiente di gestione temporanea. 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 nella seguente 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 successivi, applicherai ogni criterio in modalità dry-run, a partire da con il criterio Limitato più restrittivo. Se l'output mostra un avviso, modifica la specifica del pod in violazione per renderla conforme al criterio oppure criterio Baseline restrittivo. Se l'output non mostra alcun avviso, puoi quindi applica il criterio Base di riferimento senza la modalità dry-run.

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.

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 viene 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 su 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 tra restricted, baseline o privileged.

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

Disabilita la funzionalità PodSecurityPolicy sul tuo 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.

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 applicazioni per vedere se è possibile rafforzare ulteriormente la configurazione.
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 cluster Kubernetes numero di versione, 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 creazione dello spazio dei nomi per applicare automaticamente un'etichetta PodSecurity a tutti i nuovi spazi dei nomi. Per informazioni, consulta la pagina Esaminare il processo di creazione dello spazio dei nomi.