Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Esegui la migrazione dalle policy di sicurezza dei pod precedenti () PSP
PodSecurityPolicy
era obsoleto in Kubernetes 1.21 ed è stato rimosso in1.25
. Se si utilizza PodSecurityPolicy nel cluster, è necessario migrare alla versione integrata Kubernetes Standard di sicurezza Pod (PSS) o scegli una policy-as-code soluzione prima di aggiornare il cluster alla versione per *1.25
evitare interruzioni dei carichi di lavoro.* Seleziona una delle domande frequenti per saperne di più.
PodSecurityPolicy
Si tratta di una modifica a monte del Kubernetes progetto e non una modifica apportata in AmazonEKS. PSP è stato obsoleto in Kubernetes 1.21
e rimosso in Kubernetes 1.25
. La Kubernetes la comunità ha identificato seri problemi di usabilità con PSP. Questi includevano la concessione accidentale di autorizzazioni più ampie di quelle previste e la difficoltà di ispezionare quali PSPs si applicano in una determinata situazione. Questi problemi non potevano essere risolti senza apportare modifiche radicali. Questa è la ragione principale per cui Kubernetes la comunità ha deciso di rimuovere PSP
Per verificare se stai usando PSPs nel tuo cluster, puoi eseguire il seguente comando:
kubectl get psp
Per vedere il Pods che il PSPs nel tuo cluster stanno impattando, esegui il seguente comando. Questo comando restituisce il Pod nome, namespace e PSPs:
kubectl get pod -A -o jsonpath='{range.items[?(@.metadata.annotations.kubernetes\.io/psp)]}{.metadata.name}{"\t"}{.metadata.namespace}{"\t"}{.metadata.annotations.kubernetes\.io/psp}{"\n"}'
Prima di aggiornare il cluster a1.25
, è necessario migrare il PSPs a una di queste alternative:
-
Kubernetes PSS.
-
Policy-as-code soluzioni del Kubernetes ambiente.
In risposta al PSP deprecazione e continua necessità di controllo Pod sicurezza fin dall'inizio, la Kubernetes la community ha creato una soluzione integrata con (PSS)
È possibile consultare le best practice per la migrazione PSPs al sistema integrato PSS nella Guida alle EKS migliori pratiche
Policy-as-code le soluzioni forniscono barriere per guidare gli utenti del cluster e prevenire comportamenti indesiderati attraverso controlli automatici prescritti. Policy-as-codele soluzioni utilizzano in genere i Kubernetes Dynamic Admission Controller per intercettare i
Sono disponibili diverse soluzioni open source policy-as-code per Kubernetes. Per esaminare le migliori pratiche per la migrazione PSPs per una policy-as-code soluzione, consulta la olicy-as-code sezione P
EKSCluster Amazon con Kubernetes la versione 1.13
o superiore ha un valore predefinito PSP questo è chiamatoeks.privileged
. Questa policy viene creata nei cluster 1.24
e in quelli precedenti. Non viene utilizzato nei 1.25
cluster successivi. Amazon migra EKS automaticamente questo PSP a un PSSapplicazione basata. Non è necessaria nessuna azione da parte tua.
No. Inoltreeks.privileged
, che è un PSP creato da AmazonEKS, non vengono apportate modifiche ad altri PSPs nel tuo cluster quando esegui l'upgrade a1.25
.
No. Amazon EKS non impedirà l'aggiornamento del cluster alla versione 1.25
se non hai effettuato la migrazione da PSP ancora.
Quando un cluster che contiene un PSP viene aggiornato a Kubernetes versione1.25
, il API server non riconosce il PSP risorsa in1.25
. Ciò potrebbe comportare Pods ottenere ambiti di sicurezza errati. Per un elenco esaustivo delle implicazioni, consulta Migrare da PodSecurityPolicy al PodSecurity Built-In Admission Controller
Non prevediamo alcun impatto specifico sui carichi di lavoro Windows. PodSecurityContext ha un campo chiamato windowsOptions
PodSpec v1
API per Windows Pods. Questo utilizza PSS in Kubernetes 1.25
. Per ulteriori informazioni e procedure consigliate sull'applicazione PSS per i carichi di lavoro Windows, consulta la Guida alle EKS best practice e