TKG nel Supervisore supporta la sicurezza del pod utilizzando il controller di ammissione del criterio di sicurezza del pod, abilitato per impostazione predefinita per i cluster Tanzu Kubernetes che utilizzano TKR v1.24 e versioni precedenti.
Prerequisito: TKR 1.24 e versioni precedenti
Il contenuto di questo argomento si applica ai cluster TKG nel Supervisore di cui viene eseguito il provisioning con TKR v1.24 e versioni precedenti. Per impostazione predefinita, queste Release di Tanzu Kubernetes abilitano il controller di ammissione del criterio di sicurezza del pod.
Il successore del controller di ammissione del criterio di sicurezza del pod è il controller di ammissione della sicurezza del pod. I cluster TKG nel Supervisore di cui è stato eseguito il provisioning con TKR v1.25 e versioni successive abilitano il controller di ammissione della sicurezza del pod. Vedere Configurazione di PSA per TKR 1.25 e versioni successive.
Controller di ammissione del criterio di sicurezza del pod
I criteri di sicurezza pod Kubernetes (PSP) sono risorse a livello di cluster che controllano la sicurezza dei pod. L'utilizzo di PSP consente di controllare i tipi di pod che possono essere distribuiti e i tipi di account che possono distribuirli.
Una risorsa PodSecurityPolicy definisce un set di condizioni che un pod deve soddisfare per poter essere distribuito. Se le condizioni non vengono soddisfatte, il pod non può essere distribuito. Un singolo PodSecurityPolicy deve convalidare un pod nella sua interezza. Un pod non può avere alcune regole in un criterio e alcune in un altro. Per ulteriori informazioni, vedere Criteri di sicurezza dei pod, RBAC nella documentazione di Kubernetes.
Esistono vari modi per implementare l'uso dei criteri di sicurezza pod in Kubernetes. L'approccio tipico prevede l'utilizzo di oggetti controllo degli accessi basato sui ruoli (RBAC). ClusterRole e ClusterRoleBinding si applicano a livello dell'intero cluster, Role e RoleBinding si applicano a uno spazio dei nomi specifico. Se viene utilizzato un RoleBinding, esso consente solo di eseguire i pod nello stesso spazio dei nomi del binding. Per ulteriori informazioni, vedere RBAC nella documentazione di Kubernetes.
Esistono due modi per creare pod Kubernetes: direttamente o indirettamente. È possibile creare un pod direttamente distribuendo una specifica del pod con il proprio account utente. È possibile creare un pod indirettamente definendo alcune risorse di livello superiore, come ad esempio una Distribuzione o DaemonSet. In questo caso, un account di servizio crea il pod sottostante. Per ulteriori informazioni, vedere Account di servizio nella documentazione di Kubernetes.
Per utilizzare i PSP in modo efficace, è necessario tenere conto di entrambi i workflow di creazione pod: diretto e indiretto. Se un utente crea un pod direttamente, il PSP associato all'account utente controlla l'operazione. Se un utente crea un pod tramite un account di servizio, il PSP deve essere associato all'account del servizio utilizzato per creare il pod. Se nella specifica del pod non è specificato alcun account di servizio, viene utilizzato l'account di servizio predefinito per lo spazio dei nomi.
PodSecurityPolicy predefinito per i cluster TKG
| PSP predefinito | Autorizzazione | Descrizione | ClusterRole predefinito associato |
|---|---|---|---|
vmware-system-privileged |
Esecuzione per chiunque | PSP permissivo. Equivalente all'esecuzione di un cluster senza che sia abilitato il controllo di ammissione PSP. | psp:vmware-system-privileged può utilizzare questo PSP |
vmware-system-restricted |
Deve essere eseguito come utente non root | PSP restrittivo. Non consente l'accesso privilegiato ai container del pod, blocca possibili escalation a root e richiede l'uso di diversi meccanismi di sicurezza. | psp:vmware-system-restricted può utilizzare questo PSP |
Binding Role e ClusterRole per i cluster TKG
TKG su Supervisore non fornisce RoleBinding e ClusterRoleBinding predefiniti per i cluster TKG. In questa documentazione vengono forniti esempi utilizzabili. Vedere Applicazione del criterio di sicurezza del pod predefinito nei cluster TKG Service.
Un utente vCenter Single Sign-On a cui è concessa l'autorizzazione Modifica in un Spazio dei nomi vSphere viene assegnato al ruolo cluster-admin per qualsiasi cluster di Tanzu Kubernetes distribuito in quello spazio dei nomi. Un amministratore di cluster autenticato può utilizzare implicitamente il PSP vmware-system-privileged. Sebbene technicalmente non sia un ClusterRoleBinding, ha lo stesso effetto.
L'amministratore del cluster deve definire tutti i binding per consentire o limitare i tipi di pod che gli utenti possono distribuire in un cluster. Se si utilizza un RoleBinding, il binding consente solo l'esecuzione dei pod nello stesso spazio dei nomi del binding. Questo può essere associato ai gruppi di sistema per concedere l'accesso a tutti i pod eseguiti nello spazio dei nomi. Gli utenti non amministratori che effettuano l'autenticazione nel cluster vengono assegnati al ruolo authenticated e possono essere associati al PSP predefinito come tali.
- Un amministratore di cluster può creare pod privilegiati direttamente in qualsiasi spazio dei nomi utilizzando il proprio account utente.
- Un amministratore del cluster può creare Distribuzioni, StatefulSets e DaemonSet (ciascuno dei quali crea pod privilegiati) nello spazio dei nomi kube-system. Se si desidera utilizzare uno spazio dei nomi Kubernetes diverso, creare un'istanza RoleBinding o ClusterRoleBinding.
- Un amministratore di cluster può creare i propri PSP (oltre ai due PSP predefiniti) e associare questi PSP a qualsiasi utente. Se si definisce il proprio PSP, vedere la pagina ordine dei criteri nella documentazione di Kubernetes.
- Nessun utente autenticato può creare pod privilegiati o non privilegiati finché l'amministratore del cluster non associa PSP agli utenti autenticati.
Per esempi di binding, vedere Applicazione del criterio di sicurezza del pod predefinito nei cluster TKG Service.
