Passo 1: controlla che tutti i pod vengano eseguiti in PSP ibm - privileged - psp

Completa la seguente procedura per assicurarti che tutti i pod vengano eseguiti in ibm-privileged-psp PSP.

Una differenza tra Pod Security Admission e PodSecurityPolicies è che Pod Security Admission è in fase di convalida mentre PodSecurityPolicies può essere in fase di mutazione. Questo rende importante che i pod utilizzino ibm-privileged-psp, che non è un PSP mutante, prima di eseguire l'upgrade. Poiché sia Pod Security Admission che ibm-privileged-psp sono in fase di convalida, i pod funzionano allo stesso modo in entrambi.

Ad esempio, se un pod è attualmente in esecuzione in ibm-restricted-psp, potrebbe impostare fsGroup e supplementalGroups su 1 nella sezione pod securityContext, in base all'intervallo MustRunAs nel PSP. Il sito ibm-restricted-psp può cambiare il baccello securityContext. Tali modifiche sono visibili come una differenza tra il securityContext del pod in esecuzione e il securityContext nel template del pod della risorsa di distribuzione o simile che crea il pod. Il ibm-privileged-psp non sta mutando, quindi un pod in esecuzione sotto di esso potrebbe essere eseguito con gruppi differenti e potrebbe non essere in grado di accedere ai dati memorizzati in una PVC esistente.

1. Ottieni i dettagli di tutti i pod e controlla i loro PSP.

   kubectl get pods -A -o jsonpath="{.items[*].metadata.annotations.kubernetes\.io\/psp}" | tr " " "\n" | sort -u
   

2. Esaminare l'output del comando per tutti i PSP che non sono ibm-privileged-psp. Se i tuoi pod utilizzano un PSP differente, devi aggiornare la tua applicazione per utilizzare ibm-privileged-psp prima di eseguire l'upgrade del tuo cluster. Se non sono elencati altri PSP, è possibile continuare con l'aggiornamento.

L'aggiornamento a 1.25 non è consigliato se l'output elenca un PSP diverso da ibm-privileged-psp PSP.

Passo 2: verifica che il bind del ruolo cluster privileged - psp - user utilizzi la configurazione predefinita

Completa la seguente procedura per verificare che il bind del ruolo cluster privileged-psp-user utilizzi la configurazione predefinita. Ciò garantisce che tutti gli utenti e gli account di servizio siano autorizzati a utilizzare il ibm-restricted-psp tramite il bind del ruolo del cluster privileged-psp-user.

L'aggiornamento a 1.25 ha esito negativo se il bind del ruolo cluster non ha il valore predefinito role e subjects esattamente come mostrato nel seguente esempio.

1. Ottieni i dettagli del bind del ruolo cluster privileged-psp-user.

   kubectl get clusterrolebinding privileged-psp-user -o yaml
   

2. Esaminare role e subjects nell'output. Se l'output è diverso dal seguente esempio, non eseguire l'aggiornamento a 1.25. Se il tuo bind del ruolo cluster privileged-psp-user corrisponde al seguente esempio, puoi continuare con l'upgrade.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     creationTimestamp: "2022-10-06T20:12:36Z"
     name: privileged-psp-user
     resourceVersion: "151862"
     uid: 15014736-94d2-4cba-a3a8-92dd36de453b
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: ibm-privileged-psp-user
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:masters
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:nodes
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:serviceaccounts
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:authenticated
   

Passo 3: verifica che il bind del ruolo cluster restricted - psp - user utilizzi la configurazione predefinita

Completa la seguente procedura per verificare che il bind del ruolo cluster restricted-psp-user utilizzi la configurazione predefinita. Ciò garantisce che tutti gli utenti e gli account di servizio siano autorizzati a utilizzare il ibm-restricted-psp tramite il bind del ruolo del cluster restricted-psp-user.

Il tuo upgrade a 1.25 non riesce se il bind del ruolo cluster non include i valori predefiniti role e subjects come mostrato nel seguente esempio.

1. Ottenere i dettagli del bind del ruolo cluster restricted-psp-user

   kubectl get clusterrolebinding restricted-psp-user -o yaml
   

2. Esaminare l'output del comando. Non aggiornare il cluster alla versione 1.25 se il bind del ruolo cluster non include le impostazioni predefinite per role e subjects come mostrato nel seguente esempio.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     creationTimestamp: "2022-10-06T20:13:10Z"
     name: restricted-psp-user
     resourceVersion: "151890"
     uid: 4edb362f-9933-48d7-95e2-f41cd9f4dead
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: ClusterRole
     name: ibm-restricted-psp-user
   subjects:
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:masters
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:nodes
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:serviceaccounts
   - apiGroup: rbac.authorization.k8s.io
     kind: Group
     name: system:authenticated
   

Passo 4: verifica della presenza di PSP nonIBM

Completare la procedura per controllare se il cluster utilizza PSP nonIBM.

L'aggiornamento alla versione 1.25 non riesce se l'output del comando include ulteriori PSP rispetto a quelli nel seguente esempio. È possibile disporre di PSP aggiuntivi da applicazioni di terze parti e richiedere aggiornamenti alle applicazioni o lavorare con i fornitori dell'applicazione per determinare la corretta strategia di aggiornamento da utilizzare per tali applicazioni.

1. Elenca le tue politiche di protezione pod.

   kubectl get podsecuritypolicies -o name
   

2. Esaminare l'output del comando.

   Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+
   podsecuritypolicy.policy/ibm-anyuid-hostaccess-psp
   podsecuritypolicy.policy/ibm-anyuid-hostpath-psp
   podsecuritypolicy.policy/ibm-anyuid-psp
   podsecuritypolicy.policy/ibm-privileged-psp
   podsecuritypolicy.policy/ibm-restricted-psp
   

3. Aggiorna le tue applicazioni per utilizzare i PSP IBM.

Passo 1: abilita l'ammissione Pod Security nel tuo cluster 1.24

Abilita l'ammissione Pod Security nel tuo cluster 1.24. Questo comando aggiorna il master cluster per utilizzare la nuova configurazione di ammissione di sicurezza pod. L'aggiornamento del master del cluster potrebbe richiedere alcuni minuti.

ibmcloud ks cluster master pod-security set --cluster <CLUSTER>

Passo 2: esamina le autorizzazioni dello spazio nomi

Esamina le autorizzazioni dello spazio dei nomi nella documentazione Kubernetes esterna. Se le tue autorizzazioni Kubernetes sono gestite dai ruoli del servizio IAM, il ruolo del servizio Manager è richiesto per creare o modificare spazi dei nomi e per impostare le etichette di sicurezza del pod.

• Esaminare le autorizzazioni dello spazio dei nomi

Passo 3: semplificare e standardizzare i PSP

Ripulisci la tua configurazione di sicurezza del pod seguendo la procedura nella documentazione Kubernetes esterna. Non modificare o eliminare nessuno dei seguenti PSP: ibm-privileged-psp, ibm-anyuid-psp, ibm-anyuid-hostpath-psp, ibm-anyuid-hostaccess-psp e ibm-restricted-psp.

• Semplificare e standardizzare PodSecurityPolicies

Passo 4: aggiorna gli spazi dei nomi nel tuo cluster

Aggiorna gli spazi dei nomi nel tuo cluster seguendo la procedura nella documentazione Kubernetes esterna. Questi passi devono essere eseguiti su ogni spazio nomi nel cluster non gestito da IBM Cloud. Notare le eccezioni incluse in questa sezione.

Non eliminare o modificare le etichette di sicurezza pod per i seguenti spazi dei nomi gestiti da IBM Cloud: kube-system, ibm-system, ibm-operators.

Nel passo 3.d. Ignora la politica PodSecurity della documentazione esterna collegata in questo passo, non creare il PSP privilegiato suggerito. Se si crea questa PSP aggiuntiva, è necessario eliminarla prima di eseguire l'aggiornamento alla versione 1.25, come descritto nei requisiti di aggiornamento. Utilizza invece il seguente comando per creare un RoleBinding per il ruolo cluster ibm-privileged-psp-user : kubectl create -n $NAMESPACE rolebinding disable-psp --clusterrole ibm-privileged-psp-user --group system:serviceaccounts:$NAMESPACE.

• Aggiorna spazi dei nomi

Passo 5: esamina il processo di creazione dello spazio dei nomi

Esamina le informazioni nella documentazione Kubernetes esterna per assicurarti che il profilo di sicurezza del pod sia applicato a qualsiasi nuovo spazio dei nomi creato nel tuo cluster.

• Processi di creazione dello spazio dei nomi di revisione

Passo 6: facoltativo. Disattivare la funzione PSP nel cluster

1. Disabilita il controller di ammissione PodSecurityPolicy nel cluster. Questo comando aggiorna il master cluster per utilizzare la nuova configurazione.

   ibmcloud ks cluster master pod-security policy disable --cluster <cluster>
   

2. Attendere qualche minuto per il completamento dell'aggiornamento del master cluster.
3. Elimina i tuoi PSP e tutti i Roles, ClusterRoles, RoleBindings e ClusterRoleBindings associati. Assicurati che i componenti che elimini non concedano altre autorizzazioni non correlate di cui potresti aver bisogno altrove. Non eliminare i seguenti PSP: ibm-privileged-psp, ibm-anyuid-psp, ibm-anyuid-hostpath-psp ibm-anyuid-hostaccess-psp e ibm-restricted-psp. Non eliminare le seguenti ClusterRoles e ClusterRoleBindings: privileged-psp-user e restricted-psp-user.

Se hai bisogno di riabilitare i PSP nel tuo cluster 1.24, esegui ibmcloud ks cluster master pod-security policy enable --cluster <cluster>. Questo comando aggiorna il master cluster per utilizzare la configurazione PSP.

Fase 7: facoltativo. Aggiorna il tuo cluster

Aggiorna il tuo cluster alla versione 1.25 per utilizzare l'ammissione Pod Security. In alternativa, mantieni il tuo cluster alla versione 1.24 con l'ammissione Pod Security abilitata fino a quando non sei pronto per l'upgrade.