Migrar de PodSecurityPolicy para o controlador de admissão do PodSecurity

Autopilot Padrão

Nesta página, mostramos como continuar aplicando muitos controles de segurança no nível do pod aos clusters do Google Kubernetes Engine (GKE) migrando de PodSecurityPolicy para o controlador de admissão do PodSecurity.

Visão geral

O PodSecurityPolicy era um controlador de admissão do Kubernetes que permitia aplicar controles de segurança no nível do pod, como os padrões de segurança de pods do Kubernetes, fornecendo controle granular sobre a configuração de segurança das cargas de trabalho implantadas. O projeto Kubernetes suspendeu o uso do PodSecurityPolicy e removeu o recurso inteiramente no Kubernetes v1.25.

Se você usa o PodSecurityPolicy nos clusters do GKE, desative o recurso antes de fazer upgrade para a versão 1.25 e posteriores do GKE.

Para saber mais sobre a suspensão de uso e a remoção de PodSecurityPolicy, consulte Suspensão do PodSecurityPolicy.

PodSecurity e PodSecurityPolicy

O controlador de admissão PodSecurity está disponível e é ativado por padrão em clusters que executam as seguintes versões do GKE:

Versão 1.25 ou posterior: estável
Versão 1.23 e 1.24: Beta

PodSecurity permite que você aplique as políticas definidas nos Padrões de segurança do pod nas cargas de trabalho implantadas. PodSecurity permite que você continue a implementar configurações de segurança recomendadas no nível do pod nos clusters após a migração do PodSecurityPolicy. Ao contrário do PodSecurityPolicy, o PodSecurity não é compatível com configurações personalizadas.

Requisitos e limitações

PodSecurity está disponível na versão Beta nas versões 1.23 e 1.24 do GKE e na versão estável do GKE 1.25 e posteriores.
PodSecurity não encerra pods que já estão em execução nos nós, mesmo que violem a política aplicada.
PodSecurity não modifica campos. Se você usar campos mutantes no PodSecurityPolicy, modifique as especificações do pod para garantir que esses campos estejam presentes ao implantar as cargas de trabalho.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Ativar a API Google Kubernetes Engine.

Ativar a API Google Kubernetes Engine

Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.
Observação: para instalações atuais da CLI gcloud, defina as propriedades compute/region e compute/zone. Ao definir locais padrão, é possível evitar erros na gcloud CLI, como: One of [--zone, --region] must be supplied: Please specify location.

Verifique se você tem um GKE Autopilot ou um cluster padrão executando a versão 1.23 ou mais recente.
- Para clusters do Autopilot, inscreva-se em um canal de lançamento em que a versão padrão seja 1.23 ou mais recente.
- Para clusters padrão, inscreva-se em um canal de lançamento ou faça upgrade do cluster para uma versão específica.
Verifique seus recursos PodSecurityPolicy para modificar as configurações de campo. Adicione esses campos aos manifestos do pod para que todas as cargas de trabalho que já estão em execução nos nós estejam em conformidade com uma política definida nos padrões de segurança do pod. Veja as instruções em Simplificar e padronizar as políticas de segurança de pods.

Configurar o controlador de admissão do PodSecurity no cluster

O controlador de admissão PodSecurity aplica os Padrões de segurança do pod no nível do namespace. É preciso configurar o controlador para aplicar uma das políticas definidas pelos padrões de segurança do pod em cada namespace. As seguintes políticas estão disponíveis:

Restrito: a política mais restritiva. Em conformidade com as práticas recomendadas de aumento da proteção de pods.
Valor de referência: política minimamente restritiva que impede os escalonamentos de privilégios conhecidos. Permite todos os valores padrão dos campos nas especificações do pod.
Privilégio: política irrestrita que permite qualquer coisa, incluindo escalonamentos de privilégios conhecidos. Aplique esta política com cuidado.

Para migrar a configuração do PodSecurityPolicy para o controlador de admissão PodSecurity, faça o seguinte em todos os namespaces no cluster. Essas etapas são descritas em detalhes nas seções a seguir.

Aplique a política Restrito no modo dry-run ao namespace e verifique se há violações.
Se os pods violarem a política Restrito, aplique a política Valor de referência menos restritiva no modo dry-run ao namespace e verifique se há violações.
Se os pods violarem a política de valor de referência, modifique as especificações do pod para corrigir as violações.
Quando a política Valor de referência não retornar mais violações, aplique a política no modo enforce ao namespace.

Para evitar um possível inatividade se PodSecurity rejeitar novos pods, execute estas etapas em um ambiente de preparo. Como alternativa, é possível aplicar a política identificada no modo audit em vez de enforce e analisar seus registros de auditoria para encontrar possíveis pods rejeitados.

O modo audit não aplica a política. O GKE implanta os pods e adiciona entradas aos registros de auditoria do GKE.

Listar todos os namespaces no cluster

Veja uma lista de todos os namespaces no cluster. Repita as etapas nas seções a seguir para cada namespace na lista, exceto:

kubectl get ns

Nas seguintes versões do GKE, o GKE ignora as políticas aplicadas ao namespace kube-system:

1.23.6-gke.1900 e mais recente
1.24.0-gke.1200 e mais recente

Em versões anteriores do GKE, evite a aplicação de políticas em kube-system.

Aplicar cada política dos padrões de segurança do pod no modo de teste

Nas etapas a seguir, você aplicará cada política no modo dry-run, começando com a política mais restrita. Se a saída mostrar um aviso, modifique a especificação do pod que viola a política para obedecer à política ou tente usar a política de valor de referência menos restritiva. Se a saída não exibir um aviso, será possível aplicar a política Valor de referência sem o modo dry-run.

Aplique a política Restrito no modo dry-run:
```
kubectl label --dry-run=server --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=restricted
```
Se um pod no namespace violar a política restrita, a saída será semelhante a esta:
```
Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "restricted:latest"
namespace/NAMESPACE labeled
```
Se a política Restrito exibir um aviso, modifique os pods para corrigir a violação e tente o comando novamente. Como alternativa, tente a política de Valor de referência menos restritiva na etapa a seguir.

Aplique a política Valor de referência no modo dry-run:

kubectl label --dry-run=server --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=baseline

Se um pod no namespace violar a política de valor de referência, a saída será semelhante a esta:

Warning: existing pods in namespace "NAMESPACE" violate the new PodSecurity enforce level "baseline:latest"
namespace/NAMESPACE labeled

Se os pods violarem a política de valor de referência, modifique-os para corrigir as violações e repita essa etapa até o GKE não exibir mais um aviso.

Aplicar a política em um namespace

Quando você identificar a política que funciona para um namespace, aplique a política ao namespace no modo enforce:

kubectl label --overwrite ns NAMESPACE \
    pod-security.kubernetes.io/enforce=POLICY

Substitua POLICY pelo nome da política, que pode ser restricted, baseline ou privileged.

Repita as etapas anteriores para cada namespace no cluster.

Desativar o recurso PodSecurityPolicy no cluster

Depois de configurar o controlador de admissão PodSecurity para todos os namespaces no cluster, desative o recurso PodSecurityPolicy:

gcloud beta container clusters update CLUSTER_NAME \
    --no-enable-pod-security-policy

Substitua CLUSTER_NAME pelo nome do cluster do GKE.

Quando você faz upgrade do cluster para a versão 1.25 do GKE, o GKE remove automaticamente todos os objetos PodSecurityPolicy, incluindo os adicionados pelo GKE, o Controlador de Políticas e qualquer objeto PodSecurityPolicy definido anteriormente.

Recomendações

Sempre que possível, tente seguir a política restrita. Faça uma auditoria nos seus aplicativos para ver se a configuração pode ser reforçada.
É possível bloquear o modo de segurança do pod para uma versão secundária específica do Kubernetes adicionando o rótulo pod-security.kubernetes.io/MODE-version: VERSION aos comandos kubectl label nas etapas anteriores. Substitua VERSION pelo número da versão do Kubernetes, como v1.24.
Depois de desativar o recurso PodSecurityPolicy, revise seus aplicativos em execução para verificar se há interrupções ou lacunas na configuração de segurança.
Depois de configurar PodSecurity, atualize o processo de criação de namespace para aplicar automaticamente um rótulo PodSecurity a todos os novos namespaces. Para mais informações, consulte Analisar o processo de criação de namespace.