O Tanzu Kubernetes Grid Service provisiona clusters do Tanzu Kubernetes com PodSecurityPolicy Admission Controller ativado. Isso significa que a política de segurança do pod é necessária para implantar cargas de trabalho. Os administradores de cluster podem implantar pods de sua conta de usuário em qualquer namespace e de contas de serviço no namespace do sistema kube. Para todos os outros casos de uso, você deve associar explicitamente a um objeto PodSecurityPolicy. Os clusters incluem políticas de segurança de pod padrão que você pode associar ou criar suas próprias.
Sobre as políticas de segurança do pod do Kubernetes
As políticas de segurança de pod (PSPs) do Kubernetes são recursos de nível de cluster que controlam a segurança dos pods. O uso de PSPs oferece controle sobre os tipos de pods que podem ser implantados e os tipos de contas que podem implantá-los.
Um recurso PodSecurityPolicy define um conjunto de condições que um pod deve satisfazer para ser implantado. Se as condições não forem atendidas, o pod não poderá ser implantado. Uma única PodSecurityPolicy deve validar um pod em sua totalidade. Um pod não pode ter algumas de suas regras em uma política e algumas em outra.
Existem várias maneiras de implementar o uso de políticas de segurança de pod no Kubernetes. A abordagem típica é usando objetos de controle de acesso baseado em função (RBAC). ClusterRole e ClusterRoleBinding aplicam-se a todo o cluster; Role and RoleBinding aplicam-se a um namespace específico. Se uma RoleBinding for usada, ela só permitirá que os pods sejam executados no mesmo namespace que a associação.
Há duas maneiras de criar pods do Kubernetes: direta ou indiretamente. Você cria um pod diretamente implantando uma especificação de pod com sua conta de usuário. Você cria um pod indiretamente definindo algum recurso de nível superior, como uma implantação ou um DaemonSet. Nesse caso, uma conta de serviço cria o pod subjacente.
Para usar PSPs de forma eficaz, você deve considerar ambos os fluxos de trabalho de criação de pods. Se um usuário criar um pod diretamente, o PSP vinculado à conta de usuário controlará a operação. Se um usuário criar um pod por meio de uma conta de serviço, o PSP deverá ser vinculado à conta de serviço usada para criar o pod. Se nenhuma conta de serviço for especificada na especificação do pod, a conta de serviço padrão para o namespace será usada.
Para obter mais informações, consulte Políticas de segurança de pod , RBAC e contas de serviço na documentação do Kubernetes.
PodSecurityPolicy padrão para clusters do Tanzu Kubernetes
| PSP padrão | Permissão | Descrição | ClusterRole padrão associado |
|---|---|---|---|
vmware-system-privileged |
Executar como qualquer | PSP permissivo. Equivalente a executar um cluster sem o Controlador de Admissão PSP ativado. | psp:vmware-system-privileged pode usar este PSP |
vmware-system-restricted |
Deve ser executado como não raiz | PSP restritivo. Não permite acesso privilegiado a contêineres de pod, bloqueia possíveis escalonamentos para a raiz e requer o uso de vários mecanismos de segurança. | psp:vmware-system-restricted pode usar este PSP |
Nenhuma associação padrão para Tanzu Kubernetes clusters
O Tanzu Kubernetes Grid Service não fornece RoleBinding e ClusterRoleBinding padrão para clusters Tanzu Kubernetes.
Um usuário vCenter Single Sign-On que recebe a permissão Editar em um vSphere Namespace é atribuído à função cluster-admin para qualquer cluster Tanzu Kubernetes implantado nesse namespace. Um administrador de cluster autenticado pode usar implicitamente o vmware-system-privileged PSP. Embora não seja tecnicamente uma ClusterRoleBinding, ela tem o mesmo efeito.
O administrador do cluster deve definir quaisquer associações para permitir ou restringir os tipos de pods que os usuários podem implantar em um cluster. Se uma RoleBinding for usada, a associação só permitirá que os pods sejam executados no mesmo namespace que a associação. Isso pode ser emparelhado com grupos do sistema para conceder acesso a todos os pods executados no namespace. Os usuários não administradores que se autenticam no cluster são atribuídos à função authenticated e podem ser vinculados ao PSP padrão como tal. Consulte o Conceder acesso de desenvolvedor a Tanzu Kubernetes clusters.
Efeito da PodSecurityPolicy padrão em Tanzu Kubernetes clusters
- Um administrador de cluster pode criar pods com privilégios diretamente em qualquer namespace usando sua conta de usuário.
- Um administrador de cluster pode criar Implantações, StatefulSets e DaemonSet (cada um dos quais cria pods com privilégios) no namespace kube-system. Se você quiser usar um namespace diferente, consulte Tanzu Kubernetes Tutorial do livro de visitas.
- Um administrador de cluster pode criar seus próprios PSPs (além dos dois PSPs padrão) e associar esses PSPs a qualquer usuário. Se você definir seu próprio PSP, consulte Ordem da política na documentação do Kubernetes.
- Nenhum usuário autenticado pode criar pods com ou sem privilégios até que o administrador do cluster associe PSPs aos usuários autenticados. Consulte o Tanzu Kubernetes Tutorial do livro de visitas.
