Déployez l'application Guestbook sur votre cluster Tanzu Kubernetes pour explorer la stratégie de sécurité de l'espace pour les comptes de service, ainsi que le déploiement et la création de services.
Le déploiement de l'application Guestbook est un moyen courant d'explorer Kubernetes. Si vous déployez tous les fichiers YAML Guestbook dans un cluster Tanzu Kubernetes provisionné par Service Tanzu Kubernetes Grid, l'espace d'applications n'est pas créé. Le message d'erreur suivant s'affiche lorsque vous exécutez la commande kubectl describe pod :
“Error: container has runAsNonRoot and image will run as root”
L'application Guestbook utilise à la fois les ressources deployment et replicaset pour déployer des conteneurs privilégiés dans l'espace de noms par défaut. Étant donné que le contrôleur PodSecurityPolicy est activé pour les clusters Tanzu Kubernetes, lorsqu'un utilisateur de cluster tente de créer l'espace d'application Guestbook, les comptes de service de ces contrôleurs sont comparés à la stratégie PodSecurityPolicy. Si un PSP approprié n'est pas lié à ces comptes de service, l'application n'est pas déployée.
Par défaut, les administrateurs Tanzu Kubernetes peuvent créer des espaces privilégiés directement dans n'importe quel espace de noms à l'aide de leur compte d'utilisateur. Toutefois, l'application Guestbook déploie des conteneurs privilégiés à l'aide de comptes de service. Un administrateur de cluster peut créer des ressources Deployments, StatefulSets et DaemonSet dans l'espace de noms kube-system. Toutefois, l'application Guestbook déploie ces ressources dans l'espace de noms par défaut. En outre, les utilisateurs non-administrateurs ne peuvent pas créer des espaces privilégiés ou sans privilèges, sans la PSP et les liaisons appropriées.
Une solution consiste à créer des liaisons vers la PSP privilégiée par défaut pour permettre le déploiement de l'application Guestbook. La stratégie PodSecurityPolicy privilégiée autorise les espaces d'exécution en tant qu'utilisateur racine et les conteneurs privilégiés pour les comptes liés. Vous pouvez créer une liaison ClusterRoleBinding qui applique vmware-system-privileged à l'échelle du cluster, mais cela peut violer le principe du moindre privilège en accordant plus d'autorisations que nécessaire. Une meilleure approche consiste à créer une liaison RoleBinding qui permet aux comptes de service système d'utiliser la stratégie PodSecurityPolicy privilégiée dans l'espace de noms par défaut. Pour plus d'informations, consultez Exemples de liaisons de rôle pour la stratégie de sécurité de l'espace.
