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
.
- 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 comandikubectl label
nei passaggi precedenti. SostituisciVERSION
con il numero di versione di Kubernetes, ad esempiov1.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'etichettaPodSecurity
a tutti i nuovi spazi dei nomi. Per informazioni, consulta Esaminare il processo di creazione dello spazio dei nomi.
Passaggi successivi
- Scopri di più sugli standard di sicurezza dei pod.
- Scopri di più sul controller di ammissione
PodSecurity
. - Scopri come applicare criteri di sicurezza personalizzati a livello di pod utilizzando Gatekeeper.
- Scopri di più sul ritiro di PodSecurityPolicy.