Ammissione di sicurezza pod

L'ammissione di sicurezza del pod implementa gli standard di sicurezza del pod Kubernetes che limitano il comportamento dei pod, fornendo messaggi di avviso ed eventi di verifica kube-apiserver per i pod che violano la politica di profilo di sicurezza del pod configurata per lo spazio dei nomi pertinente.

IBM Cloud Kubernetes Service versione 1.25 e successive includono il supporto per l'ammissione di sicurezza del pod Kubernetes. Per ulteriori informazioni, vedi Pod Security Admission e Pod Security Standards nella documentazione di Kubernetes.

Pod Security Admission è sempre abilitato per IBM Cloud Kubernetes Service versione 1.25 e successive. Le versioni precedenti di Kubernetes utilizzano i criteri di sicurezza pod.

Comprensione dei profili di sicurezza

Gli standard di sicurezza del pod Kubernetes definiscono le seguenti tre profili.

Privilegiato: La configurazione di sicurezza del pod predefinita applica globalmente il profilo di sicurezza del pod privileged Kubernetes, che non è limitato e consente escalation di privilegi noti e genera avvisi e eventi di verifica in base alle politiche impostate dal profilo restricted.
Informazioni di base: Il profilo baseline è un profilo restrittivo che impedisce escalation di privilegi noti. Consente la configurazione del pod predefinita (specificata in modo minimo).
Limitato: Il profilo restricted è fortemente limitato e segue le procedure ottimali di rafforzamento del pod corrente.

Per ulteriori informazioni sui profili di sicurezza del pod, vedi Dettagli del profilo nella documentazione di Kubernetes.

L'ammissione di sicurezza pod contiene tre modalità che definiscono l'azione che il piano di controllo intraprende se viene rilevata una potenziale violazione.

applicare: Le violazioni della politica causano il rifiuto del pod.
controllo: Le violazioni della politica attivano l'aggiunta di un'annotazione di controllo all'evento registrato nel log di controllo, ma sono altrimenti consentite.
warn: Le violazioni della politica attivano un'avvertenza rivolta all'utente, ma sono altrimenti consentite.

Man mano che gli standard di sicurezza o le implementazioni dei profili cambiano per indirizzare nuove funzioni, è possibile configurare Pod Security Admission per utilizzare una versione specifica dei ruoli. Sono supportate le seguenti versioni.

Versione Kubernetes major.minor (ad esempio, v1.25)
latest

E se Pod Security Admission non fosse la scelta giusta per me?

Mentre l'ammissione di sicurezza pod è sempre abilitata, può essere uno di più controller di ammissione. Puoi configurare i controller di ammissione Kubernetes di terze parti per implementare altri modelli di politica di sicurezza adatti al tuo caso di utilizzo.

Se configuri Pod Security Admission per applicare, avvisare e controllare utilizzando il profilo privileged, il piano di controllo consente l'esecuzione di tutti i pod. È quindi possibile configurare altri controller di ammissione per rifiutarli.

È possibile installare un controller di ammissione di terze parti purché non esegua una delle seguenti azioni.

Non installa le proprie PSP (pod security policies).
Non si basa su PSP per applicare parti della politica.

Configurazione delle etichette dello spazio dei nomi di ammissione Pod Security

Puoi definire la modalità di controllo dell'ammissione che vuoi utilizzare per la sicurezza del pod in ciascuno spazio dei nomi. Kubernetes definisce una serie di etichette che puoi impostare per definire quale dei profili Pod Security Standard predefiniti vuoi utilizzare per uno spazio dei nomi. L'etichetta selezionata definisce l'azione che il piano di controllo intraprende se viene rilevata una potenziale violazione.

Per impostazione predefinita, IBM Cloud Kubernetes Service aggiunge le etichette privileged Pod Security ai seguenti spazi dei nomi. Questi spazi dei nomi sono etichettati come enforce, audit e warn utilizzando il profilo privileged.

kube-system
ibm-system
ibm-operators
calico-system (Versione 1.29 e successive)
tigera-operator (Versione 1.29 e successive)
calico-apiserver (Versione 1.31 )

Non rimuovere o modificare le etichette per questi spazi dei nomi.

Uno spazio dei nomi può essere etichettato per impostare il profilo di sicurezza del pod per uno o tutti i Pod Security Admission modes.

Ad esempio, puoi etichettare uno spazio dei nomi per applicare il profilo privileged oltre a utilizzare warn o audit utilizzando il profilo baseline.

Questa etichetta consente agli amministratori e agli sviluppatori di applicazioni di eseguire a secco le applicazioni ricercando solo avvertenze e record di verifica rispetto al profilo baseline senza rifiutare i pod. Quindi, è possibile apportare le modifiche necessarie ai carichi di lavoro prima di modificare la modalità di applicazione in baseline.

Le etichette dello spazio dei nomi Ammissione di sicurezza pod sono nel formato pod-security.kubernetes.io/<MODE>: <LEVEL> e pod-security.kubernetes.io/<MODE>-version: <VERSION>.

pod-security.kubernetes.io/enforce
pod-security.kubernetes.io/enforce-version
pod-security.kubernetes.io/audit
pod-security.kubernetes.io/audit-version
pod-security.kubernetes.io/warn
pod-security.kubernetes.io/warn-version

Per etichettare uno spazio dei nomi per applicare il profilo privileged e generare avvertenze ed eventi di verifica per violazioni del profilo baseline, utilizzare le seguenti etichette.

pod-security.kubernetes.io/enforce: privileged
pod-security.kubernetes.io/enforce-version: latest
pod-security.kubernetes.io/audit: baseline
pod-security.kubernetes.io/audit-version: latest
pod-security.kubernetes.io/warn: baseline
pod-security.kubernetes.io/warn-version: latest

Configurazione del plug-in di ammissione sicurezza pod predefinito

IBM Cloud Kubernetes Service utilizza per impostazione predefinita il seguente PodSecurityConfiguration.

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "privileged"
  enforce-version: "latest"
  audit: "privileged"
  audit-version: "latest"
  warn: "privileged"
  warn-version: "latest"
exemptions:
  usernames: []
  runtimeClasses: []
  namespaces: []

Personalizzazione della configurazione del plug-in Pod Security Admission

La configurazione del plug-in Pod Security Admission a livello di cluster imposta il comportamento enforce, audit e warn per tutti gli spazi dei nomi che non hanno etichette o esenzioni di sicurezza del pod.

Per i cluster Kubernetes 1.24 apiVersion deve essere pod-security.admission.config.k8s.io/v1beta. Per 1.25 e versioni successive è preferibile pod-security.admission.config.k8s.io/v1, ma è comunque possibile utilizzare la versione API v1beta.

Creare un file YAML contenente una risorsa PodSecurityConfiguration. È possibile utilizzare la configurazione predefinita per iniziare.

apiVersion: pod-security.admission.config.k8s.io/v1
kind: PodSecurityConfiguration
defaults:
  enforce: "privileged"
  enforce-version: "latest"
  audit: "privileged"
  audit-version: "latest"
  warn: "privileged"
  warn-version: "latest"
exemptions:
  usernames: []
  runtimeClasses: []
  namespaces: []

Effettuare le personalizzazioni che si desidera utilizzare. Esaminare le seguenti informazioni su ciascuna sezione della configurazione.
defaults

La sezione defaults della configurazione definisce i valori predefiniti a livello di cluster per gli spazi dei nomi che non hanno etichette di sicurezza del pod. I campi possono avere gli stessi valori delle etichette dello spazio dei nomi corrispondenti.

exemptions
La sezione exemptions della configurazione ti permette di creare dei pod che sono altrimenti proibiti a causa della politica associata a uno spazio dei nomi specifico. Le dimensioni di esenzione includono i seguenti casi.
- Nomi utente: le richieste degli utenti con un nome utente autenticato (o impersonato) esente vengono ignorate. I nomi utente sono generalmente utenti IAM o account di servizio. Ad esempio usernames: [ "IAM#user@example.com" ]. È anche possibile esentare il nome utente associato a un certificato client admin kubeconfig. Se si desidera specificare un certificato admin kubeconfig, il nome utente è il componente CN del certificato client corrente.
```
kubectl config view --minify -o jsonpath='{.users[0].user.client-certificate}'
/home/user/.bluemix/plugins/container-service/clusters/mycluster-cheku1620qbs90gq6mdg-admin/admin.pem
```
  Nel seguente esempio, il nome utente è IBMid-27000xxxxx-admin-2023-05-12. Se si ottiene un nuovo admin kubeconfig, il nome utente potrebbe essere diverso.
```
openssl x509 -in <client-certificate> -subject -noout`
subject=C = US, ST = San Francisco, L = CA, O = ibm-admins, CN = IBMid-27000xxxxx-admin-2023-05-12
```
- RuntimeClassNames: I pod e le risorse del carico di lavoro che specificano un nome di classe di runtime esente sono ignorati.
- Spazi dei nomi: i pod e le risorse del workload in uno spazio dei nomi esente vengono ignorati.
Salvare il file YAML delle personalizzazioni.

Eseguire il comando ibmcloud ks cluster master pod-security set.

ibmcloud ks cluster master pod-security set --cluster CLUSTER --config-file CONFIG-FILE

Quando esegui il comando ibmcloud ks cluster master pod-security set, l'ammissione di sicurezza del pod viene reimpostata sulla configurazione predefinita se non specifichi un file di configurazione.