Servizio Tanzu Kubernetes Grid esegue il provisioning dei cluster di Tanzu Kubernetes con il controller ammissione PodSecurityPolicy abilitato. Questo significa che il criterio di sicurezza pod è necessario per distribuire i carichi di lavoro. Gli amministratori del cluster possono distribuire pod dal proprio account utente in qualsiasi spazio dei nomi e da account di servizio nello spazio dei nomi kube-system. Per tutti gli altri casi d'uso, è necessario effettuare esplicitamente il binding a un oggetto PodSecurityPolicy. I cluster includono criteri di sicurezza pod predefiniti a cui effettuare il binding ed è comunque possibile crearne di propri autonomamente.
Informazioni sui criteri di sicurezza pod Kubernetes
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.
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.
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 utilizzare i PSP in modo efficace, è necessario tenere conto di entrambi i workflow di creazione pod. 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.
Per ulteriori informazioni, vedere le pagine su criteri di sicurezza dei pod, controllo degli accessi basato sui ruoli (RBAC) e account di servizio nella documentazione di Kubernetes.
PodSecurityPolicy predefinito per i cluster di Tanzu Kubernetes
| 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 |
Nessun binding predefinito per i cluster di Tanzu Kubernetes
Il Servizio Tanzu Kubernetes Grid non fornisce RoleBinding e ClusterRoleBinding predefiniti per i cluster di Tanzu Kubernetes.
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. Vedere Concessione dell'accesso agli sviluppatori ai cluster di Tanzu Kubernetes.
Effetto di PodSecurityPolicy predefinito nei cluster di Tanzu Kubernetes
- 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 diverso, vedere Tutorial di Tanzu Kubernetes Guestbook.
- 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. Vedere Tutorial di Tanzu Kubernetes Guestbook.
