Ammissione alla sicurezza del baccello

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

Red Hat OpenShift on IBM Cloud la versione 4.11 e successive include il supporto per l'ammissione della sicurezza dei pod Kubernetes. Per ulteriori informazioni, vedere Ammissione alla sicurezza del pod e Standard di sicurezza del pod nella documentazione di Kubernetes.

Pod Security Admission è sempre abilitato per Red Hat OpenShift on IBM Cloud versione 4.11 e successive. Le versioni precedenti di Kubernetes utilizzano i criteri di sicurezza pod.

Comprendere i profili di sicurezza

Gli standard di sicurezza dei pod Kubernetes definiscono i seguenti tre profili.

Privilegiato
La configurazione predefinita della sicurezza del pod applica globalmente il profilo di sicurezza del pod privileged Kubernetes, che non prevede restrizioni e consente escalation di privilegi note, e genera avvisi ed eventi di audit in base alle politiche impostate dal profilo restricted.
Informazioni di base
Il profilo baseline è un profilo restrittivo che impedisce le escalation di privilegi note. Consente la configurazione predefinita (minimamente specificata) del Pod.
Limitato
Il profilo restricted è fortemente limitato e segue le attuali best practice per l'hardening dei pod.

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

Pod Security Admission 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 dei criteri comportano l'aggiunta di un'annotazione di audit all'evento registrato nel registro di audit, ma sono altrimenti consentite.
warn
Le violazioni dei criteri provocano un avviso all'utente, ma sono altrimenti consentite.

Quando gli standard di sicurezza o le implementazioni dei profili cambiano per affrontare nuove funzionalità, è possibile configurare Pod Security Admission per utilizzare una versione specifica dei ruoli. Sono supportate le seguenti versioni.

  • Una versione Kubernetes major.minor (ad esempio, v1.25)
  • latest

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

Mentre Pod Security Admission è sempre abilitato, può essere uno dei controllori di ammissione multipli. È possibile configurare i controllori di ammissione Kubernetes di terze parti per implementare altri modelli di criteri di sicurezza adatti al proprio caso d'uso.

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

È possibile installare un controllore di ammissione di terze parti, purché non esegua nessuna delle seguenti azioni.

  • Non installa i propri criteri di sicurezza dei pod (PSP).
  • Non si affida ai PSP per far rispettare alcune parti della politica.

Configurazione delle etichette dello spazio dei nomi di ammissione di Pod Security

È possibile definire la modalità di controllo di ammissione da utilizzare per la sicurezza dei pod in ogni spazio dei nomi. Kubernetes definisce una serie di etichette che possono essere impostate per definire quale dei profili predefiniti di Pod Security Standard si desidera 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, Red Hat OpenShift on IBM Cloud aggiunge le etichette di 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
  • tigera-operator
  • calico-apiserver (Versione 4.16 e successive)

Non rimuovere o modificare le etichette di questi spazi dei nomi o di qualsiasi altro spazio dei nomi openshift-*.

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, è possibile etichettare uno spazio dei nomi per applicare il profilo privileged, oltre a usare warn o audit, usando il profilo baseline.

Questa etichetta consente agli amministratori e agli sviluppatori di applicazioni di eseguire il dry-run delle applicazioni cercando solo avvisi e record di audit rispetto al profilo baseline senza rifiutare i pod. Quindi, è possibile apportare le modifiche necessarie ai carichi di lavoro prima di cambiare la modalità di enforce in baseline.

Le etichette dello spazio dei nomi Pod Security Admission sono della forma 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 in modo da applicare il profilo privileged e generare avvisi ed eventi di audit per le 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 predefinita del plug-in Pod Security Admission

Red Hat OpenShift on IBM Cloud 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: []

Configurazione dell'ammissione alla sicurezza dei pod

È possibile configurare il comportamento di sicurezza del pod a livello di spazio dei nomi con etichette di sicurezza predefinite. Per ulteriori informazioni sulla configurazione, vedere Controllo della sincronizzazione dell'ammissione della sicurezza dei pod nella documentazione di Red Hat OpenShift. Si noti che i passaggi variano per ogni versione del cluster, quindi assicurarsi di visualizzare i passaggi per la versione corretta.

Per ulteriori informazioni sulla configurazione dei registri apiserver per Red Hat OpenShift on IBM Cloud, vedere i registri di audit del server API Kubernetes.

L'ammissione della sicurezza dei pod offre la possibilità di applicare, avvisare e generare eventi di audit per i pod che violano i profili di sicurezza. In OpenShift 4.11, la configurazione predefinita applica il profilo privilegiato, generando al contempo avvisi ed eventi di audit basati sul profilo restricted. Questo comportamento può essere controllato a livello di spazio dei nomi attraverso l'uso di etichette di sicurezza predefinite per gli spazi dei nomi. Quando i profili di sicurezza Pod vengono applicati, si possono vedere avvisi come quelli dell'esempio seguente.

`Warning: would violate PodSecurity "restricted:latest": host namespaces (hostNetwork=true, hostPID=true), privileged (container "container-00" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "container-00" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "container-00" must set securityContext.capabilities.drop=["ALL"]), restricted volume types (volume "host" uses restricted volume type "hostPath"), runAsNonRoot != true (pod or container "container-00" must set securityContext.runAsNonRoot=true), runAsUser=0 (container "container-00" must not set runAsUser=0), seccompProfile (pod or container "container-00" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")`

In questo esempio, il pod viene comunque creato e può essere eseguito finché l'account del servizio è autorizzato a un profilo SecurityContextConstraint. L'avviso indica che sono necessarie modifiche al profilo securityContext del pod e del contenitore affinché il pod possa essere eseguito sotto il profilo di sicurezza del pod specificato, come l'impostazione dell'opzione allowPrivilegeEscalation=false o che deve essere utilizzato un profilo di sicurezza del pod che consenta tali funzionalità.

Red Hat OpenShift include anche un controllore che applica le etichette degli spazi dei nomi in base ai permessi SCC degli account dei servizi in un determinato spazio dei nomi. Vengono applicate sia l'ammissione di sicurezza del pod che le SCC. È possibile utilizzare principalmente gli SCC e utilizzare il controller di sincronizzazione dell'ammissione della sicurezza del pod per regolare l'etichetta di sicurezza del pod sullo spazio dei nomi. In alternativa, è possibile utilizzare principalmente i profili di sicurezza dei pod con un binding di ruolo dello spazio dei nomi che consente a tutti gli account di servizio nello spazio dei nomi di utilizzare un SCC equivalente (o più privilegiato). Non definire vincoli di ruolo o di cluster che si applicano a livello globale, come tutti gli utenti autorizzati o tutti gli account di servizio in tutti i namespace, poiché questi vincoli possono influenzare i componenti di Red Hat OpenShift che si aspettano di essere eseguiti sotto un particolare SCC.

Risorse aggiuntive