Distribuire l'applicazione Guestbook nel cluster di Tanzu Kubernetes per esplorare il criterio di sicurezza del pod per gli account di servizio, nonché per la distribuzione e la creazione del servizio.
La distribuzione dell'applicazione Guestbook è un modo comune per esplorare Kubernetes. Se si distribuiscono tutti i file YAML di Guestbook in un cluster di Tanzu Kubernetes il cui provisioning è stato eseguito dal Servizio Tanzu Kubernetes Grid, il pod dell'applicazione non viene creato correttamente. Quando si esegue il comando kubectl describe pod, viene visualizzato il seguente messaggio di errore:
“Error: container has runAsNonRoot and image will run as root”
L'applicazione Guestbook utilizza entrambe le risorse deployment e replicaset per distribuire container privilegiati nello spazio dei nomi predefinito. Poiché il controller PodSecurityPolicy è abilitato per i cluster di Tanzu Kubernetes, quando un utente del cluster tenta di creare il pod dell'applicazione Guestbook, gli account di servizio per questi controller vengono controllati rispetto a PodSecurityPolicy. Se a questi account di servizio non è associato un PSP appropriato, l'applicazione non viene distribuita.
Per impostazione predefinita, gli amministratori di Tanzu Kubernetes possono creare pod privilegiati direttamente in qualsiasi spazio dei nomi utilizzando il loro account utente. Tuttavia, l'applicazione Guestbook distribuisce container privilegiati utilizzando gli account di servizio. Un amministratore del cluster può creare distribuzioni, StatefulSet e DaemonSet nello spazio dei nomi kube-system. Tuttavia, l'applicazione Guestbook distribuisce queste risorse nello spazio dei nomi predefinito. Inoltre, gli utenti non amministrativi non possono creare pod privilegiati o non privilegiati senza il PSP e i binding appropriati.
Una soluzione consiste nel creare binding al PSP privilegiato predefinito per consentire la distribuzione dell'applicazione Guestbook. Il PodSecurityPolicy privilegiato consente pod eseguiti come radice e container privilegiati per gli account associati. È possibile creare un ClusterRoleBinding che applichi il vmware-system-privileged in tutto il cluster, ma così facendo è possibile violare il principio del privilegio minimo concedendo più autorizzazioni di quelle necessarie. Un approccio migliore consiste nel creare un RoleBinding che consenta agli account dei servizi di sistema di utilizzare il PodSecurityPolicy privilegiato nello spazio dei nomi predefinito. Per ulteriori informazioni, vedere Esempio di binding del ruolo per il criterio di sicurezza pod.
