Implante o aplicativo Guestbook no cluster do Tanzu Kubernetes para explorar a política de segurança de pod para contas de serviço e a implantação e a criação de serviços.
A implantação do aplicativo Guestbook é uma maneira comum de explorar o Kubernetes. Se você implantar todos os arquivos YAML do Guestbook em um cluster Tanzu Kubernetes provisionado pelo Tanzu Kubernetes Grid Service, o pod do aplicativo não será criado com êxito. A seguinte mensagem de erro aparece quando você executa o comando kubectl describe pod
:
“Error: container has runAsNonRoot and image will run as root”
O aplicativo Guestbook está usando os recursos deployment
e replicaset
para implantar contêineres privilegiados no namespace padrão. Como o PodSecurityPolicy Controller está habilitado para clusters Tanzu Kubernetes, quando qualquer usuário do cluster tenta criar o pod do aplicativo Guestbook, as contas de serviço para esses controladores são verificadas em relação à PodSecurityPolicy. Se um PSP apropriado não estiver vinculado a essas contas de serviço, o aplicativo não será implantado.
Por padrão, os administradores do Tanzu Kubernetes podem criar pods com privilégios diretamente em qualquer namespace usando sua conta de usuário. No entanto, o aplicativo Guestbook implanta contêineres privilegiados usando contas de serviço. Um administrador de cluster pode criar implantações, StatefulSets e DaemonSet no namespace kube-system
. No entanto, o aplicativo Guestbook implanta esses recursos no namespace padrão. Além disso, os usuários não administrativos não podem criar pods com ou sem privilégios sem o PSP e as associações adequadas.
Uma solução é criar associações com o PSP privilegiado padrão para permitir que o aplicativo Guestbook seja implantado. A PodSecurityPolicy privilegiada permite a execução de pods como raiz e contêineres privilegiados para contas vinculadas. Você pode criar uma ClusterRoleBinding que aplica o vmware-system-privileged
em todo o cluster, mas isso pode violar o princípio do menor privilégio, concedendo mais permissões do que o necessário. Uma abordagem melhor é criar um RoleBinding que permita que as contas de serviço do sistema usem a PodSecurityPolicy privilegiada no namespace padrão. Para obter mais informações, consulte Exemplo de associações de função para a política de segurança do pod.