Migre da PodSecurityPolicy para o controlador de admissão PodSecurity

Autopilot Padrão

Esta página mostra como continuar a aplicar muitos controlos de segurança ao nível do pod nos seus clusters do Google Kubernetes Engine (GKE) migrando da PodSecurityPolicy para o controlador de admissão PodSecurity.

Vista geral

A PodSecurityPolicy era um controlador de admissão do Kubernetes que lhe permitia aplicar controlos de segurança ao nível do pod, como as normas de segurança do pod do Kubernetes, o que lhe dava um controlo detalhado sobre a configuração de segurança das suas cargas de trabalho implementadas. O projeto Kubernetes descontinuou a PodSecurityPolicy e removeu a funcionalidade por completo no Kubernetes v1.25.

Se usar atualmente a PodSecurityPolicy nos seus clusters do GKE, desative a funcionalidade antes de atualizar para a versão 1.25 e posterior do GKE.

Para saber mais sobre a descontinuação e a remoção da PodSecurityPolicy, consulte o artigo Descontinuação da PodSecurityPolicy.

PodSecurity e PodSecurityPolicy

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

• Versão 1.25 ou posterior: estável
• Versão 1.23 e versão 1.24: beta

O PodSecurity permite-lhe aplicar as políticas definidas nas normas de segurança de pods nas suas cargas de trabalho implementadas. PodSecurity permite-lhe continuar a implementar configurações de segurança ao nível do pod nos seus clusters após a migração da PodSecurityPolicy. Ao contrário da PodSecurityPolicy, o PodSecurity não suporta configurações personalizadas.

Requisitos e limitações

• PodSecurity está disponível em versão beta nas versões 1.23 e 1.24 do GKE e em versão estável na versão 1.25 e posteriores do GKE.
• PodSecurity não termina os pods que já estão a ser executados nos seus nós, mesmo que violem a política aplicada.
• PodSecurity não altera campos. Se usar quaisquer campos de mutação na sua PodSecurityPolicy, modifique a especificação do pod para garantir que esses campos estão presentes quando implementar as cargas de trabalho.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.
  Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

• Certifique-se de que tem um cluster do GKE Autopilot ou Standard com a versão 1.23 ou posterior.
  • Para clusters do Autopilot, inscreva-se num canal de lançamento em que a versão predefinida seja 1.23 ou posterior.
  • Para clusters padrão, inscreva-se num canal de lançamento ou atualize o cluster para uma versão específica.
• Verifique os seus recursos PodSecurityPolicy para configurações de campos de mutação. Adicione esses campos aos seus manifestos de POD para que todas as cargas de trabalho já em execução nos seus nós estejam em conformidade com uma política definida nas normas de segurança de POD. Para ver instruções, consulte o artigo Simplifique e padronize as políticas de segurança de pods.

Configure o controlador de admissão PodSecurity no seu cluster

O controlador de admissão PodSecurity aplica as normas de segurança de pods ao nível do espaço de nomes. Tem de configurar o controlador para aplicar uma das políticas definidas pelas normas de segurança de pods em cada espaço de nomes. Estão disponíveis as seguintes políticas:

• Restrito: política mais restritiva. Está em conformidade com as práticas recomendadas de reforço de pods.
• Base: política minimamente restritiva que impede a escalada de privilégios conhecida. Permite todos os valores predefinidos para campos nas especificações de agrupamentos.
• Privilegiado: política não restrita que permite tudo, incluindo escalamentos de privilégios conhecidos. Aplique esta política com precaução.

Para migrar a configuração da PodSecurityPolicy para o controlador de admissão PodSecurity, faça o seguinte em todos os espaços de nomes no cluster. Estes passos são descritos detalhadamente nas secções seguintes.

1. Aplique a política Restrita no modo dry-run ao espaço de nomes e verifique se existem violações.
2. Se os seus pods violarem a política Restricted, aplique a política Baseline menos restritiva no modo dry-run ao espaço de nomes e verifique se existem violações.
3. Se os seus Pods violarem a política de base, modifique as especificações dos Pods para corrigir as violações.
4. Quando a política de base deixar de devolver violações, aplique a política no modo enforce ao espaço de nomes.

Para evitar uma potencial indisponibilidade se o PodSecurity rejeitar novos pods, siga estes passos num ambiente de teste. Em alternativa, pode aplicar a política identificada no modo audit em vez do modo enforce e rever os registos de auditoria para encontrar potenciais pods rejeitados.

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

Liste todos os espaços de nomes no seu cluster

Obtenha uma lista de todos os espaços de nomes no seu cluster. Repita os passos nas secções seguintes para cada espaço de nomes na lista:

kubectl get ns

Nas seguintes versões do GKE, o GKE ignora as políticas que aplica ao espaço de nomes kube-system:

• 1.23.6-gke.1900 e posterior
• 1.24.0-gke.1200 e posterior

Nas versões anteriores do GKE, evite aplicar políticas em kube-system.

Aplique cada política das normas de segurança de pods no modo de execução de ensaio

Nos passos seguintes, vai aplicar cada política no modo dry-run, começando pela política restrita mais restritiva. Se o resultado apresentar um aviso, modifique a especificação do pod em violação para agir em conformidade com a política ou experimente a política Baseline menos restritiva. Se o resultado não apresentar um aviso, pode aplicar a política Base sem o modo dry-run.

1. 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 espaço de nomes violar a política restrita, o resultado é semelhante ao seguinte:

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

   Se a política Restrita apresentar um aviso, modifique os seus pods para corrigir a violação e tente o comando novamente. Em alternativa, experimente a política Base menos restritiva no passo seguinte.

2. Aplique a política Base no modo dry-run:

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

   Se um pod no espaço de nomes violar a política de base, o resultado é semelhante ao seguinte:

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

Se os seus pods violarem a política de base, modifique-os para corrigir as violações e repita este passo até o GKE deixar de apresentar um aviso.

Aviso: opcionalmente, pode usar a política Privilegiada, que não tem restrições. Antes de usar a política Privileged, certifique-se de que confia em todas as cargas de trabalho e utilizadores que têm acesso ao espaço de nomes. A política de privilégios permite escalamentos de privilégios conhecidos, mas pode ser necessária para determinadas cargas de trabalho de sistema com privilégios.

Aplique a política num espaço de nomes

Quando identificar a política que funciona para um espaço de nomes, aplique a política ao espaço de nomes no modo enforce:

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

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

Certifique-se de que repete os passos anteriores para cada espaço de nomes no seu cluster.

Desative a funcionalidade PodSecurityPolicy no cluster

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

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

Substitua CLUSTER_NAME pelo nome do seu cluster do GKE.

Nota: depois de desativar a funcionalidade, não tem de remover manualmente os objetos PodSecurityPolicy restantes. Quando executa kubectl get psp, o GKE pode apresentar as políticas restantes, mas o GKE não aplica essas políticas.

Quando atualiza o cluster para a versão 1.25 do GKE, o GKE remove automaticamente todos os objetos PodSecurityPolicy restantes, incluindo os adicionados pelo GKE, Policy Controller e quaisquer objetos PodSecurityPolicy que tenha definido anteriormente.

Recomendações

• Tente agir em conformidade com a política restrita sempre que possível. Audite as suas aplicações para ver se a configuração pode ser reforçada ainda mais.
• Pode bloquear o modo de segurança do pod numa versão secundária específica do Kubernetes adicionando a etiqueta pod-security.kubernetes.io/MODE-version: VERSION aos comandos kubectl label nos passos anteriores. Substitua VERSION pelo número da versão do Kubernetes, como v1.24.
• Depois de desativar a funcionalidade PodSecurityPolicy, reveja as aplicações em execução para verificar se existem interrupções ou lacunas na configuração de segurança.
• Depois de configurar PodSecurity, atualize o processo de criação do espaço de nomes para aplicar automaticamente uma etiqueta PodSecurity a todos os novos espaços de nomes. Para mais informações, consulte o artigo Reveja o processo de criação do espaço de nomes

O que se segue?

• Saiba mais sobre as normas de segurança de pods.
• Saiba mais sobre o PodSecuritycontrolador de admissão.
• Saiba como aplicar políticas de segurança personalizadas ao nível do pod através do Gatekeeper.
• Leia acerca da descontinuação da PodSecurityPolicy.