O TKG em Supervisor é compatível com a segurança do pod por meio do controlador de admissão Pod Security, que é ativado por padrão a partir do Kubernetes v1.23. Anteriormente, a segurança do pod era aplicada usando o controlador de admissão da Política de Segurança do Pod, que era ativado por padrão para clusters Tanzu Kubernetes. Se você estiver usando o TKR v1.22 ou anterior, precisará vincular os usuários à política de segurança do pod para implantar cargas de trabalho de cluster.
Controlador de admissão de segurança do pod
O controlador de admissão de Segurança do Pod é o sucessor do controlador de admissão da Política de Segurança do Pod. O controlador de admissão Segurança do pod aplica restrições de segurança do pod no nível do namespace Kubernetes quando os pods são criados, em vez de no nível do pod antes da criação dos pods, como é o caso do controlador de admissão Política de Segurança do pod. A partir do Kubernetes v1.23, o controlador de admissão do Pod Security é um feature gate.
Atualmente, os clusters do TKG 2 em Supervisor não ativam o controlador de admissão do Pod Security. Se você estiver provisionando o TKG 2 em clusters Supervisor, precisará continuar usando a política de segurança de pod para implantar cargas de trabalho. Consulte Controlador de admissão da política de segurança do pod.
Controlador de admissão da política de segurança do pod
As políticas de segurança de pod do Kubernetes (PSPs) 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 implantável. Se as condições não forem atendidas, o pod não poderá ser implantado. Um único 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. Para obter mais informações, consulte Políticas de segurança do pod, RBAC na documentação do Kubernetes.
Há 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 se aplicam a todo o cluster; Role e RoleBinding se aplicam a um namespace específico. Se um RoleBinding for usado, ele só permitirá que os pods sejam executados no mesmo namespace que a associação. Para obter mais informações, consulte RBAC na documentação do Kubernetes.
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 um Deployment ou DaemonSet. Nesse caso, uma conta de serviço cria o pod subjacente. Para obter mais informações, consulte Contas de serviço na documentação do Kubernetes.
Para usar os PSPs com eficiência, você deve considerar os dois fluxos de trabalho de criação de pod: direto e indireto. Se um usuário criar um pod diretamente, o PSP associado à 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á estar associado à 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 do namespace será usada.
PodSecurityPolicy padrão para clusters TKG
| 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 habilitado. | 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 escalações para raiz e requer o uso de vários mecanismos de segurança. | psp:vmware-system-restricted pode usar este PSP |
Associações de função e clusterRole para clusters TKG
O TKG em Supervisor não fornece RoleBinding e ClusterRoleBinding padrão para clusters do TKG. Os exemplos que você pode usar são fornecidos nesta documentação. Consulte Exemplo de RBAC para política de segurança de pod.
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 um ClusterRoleBinding, ele 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 um RoleBinding for usado, a associação só permitirá que os pods sejam executados no mesmo namespace que a associação. Isso pode ser emparelhado com grupos de sistemas para conceder acesso a todos os pods executados no namespace. Os usuários que não são administradores que se autenticam no cluster são atribuídos à função authenticated e podem ser associados ao PSP padrão como tal.
- 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 privilegiados) no namespace kube-system. Se você quiser usar um namespace Kubernetes diferente, crie um RoleBinding para ele ou um ClusterRoleBinding.
- Um administrador de cluster pode criar seus próprios PSPs (além dos dois PSPs padrão) e associá-los 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 vincule os PSPs aos usuários autenticados.
Para obter exemplos de associação, consulte Exemplo de RBAC para política de segurança de pod.
