Pod Security Admission substituiu o PodSecurityPolicy no Kubernetes: o que reconfigurar antes do próximo upgrade

O PodSecurityPolicy foi removido do Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps → em uma atualização das versões mais recentes do projeto, e o Pod Security Admission, estável desde a v1.25, é o mecanismo nativo que ficou no lugar. Times de plataforma que adiaram a migração correm risco de quebrar workloads em silêncio no próximo upgrade de cluster.

Nota da redação: este artigo afirma que muitos clusters de produção no Brasil rodaram anos em versões antigas, sustentados por fornecedores de nuvem gerenciada, e só agora estão sendo forçados a migrar por fim de suporte. Essa alegação de contexto de mercado não pôde ser confirmada em nenhuma fonte disponível e deve ser lida como pano de fundo hipotético, não como dado verificado. Da mesma forma, detalhes sobre o funcionamento interno do antigo PodSecurityPolicy (vínculo com ClusterRole e RoleBinding, exceções configuráveis em runtime) não constam na documentação técnica consultada sobre Pod Security Admission e não puderam ser verificados contra fonte oficial. O conteúdo técnico sobre Pod Security Admission em si, modos, labels, métricas e versão 1.25, foi confirmado na documentação oficial do Kubernetes.

O PodSecurityPolicy foi removido do Kubernetes em uma atualização das versões mais recentes do projeto, e o Pod Security Admission, estável desde a v1.25, é o mecanismo nativo que ficou no lugar. Times de plataforma que adiaram a migração correm risco de quebrar workloads em silêncio no próximo upgrade de cluster.

O PodSecurityPolicy foi removido do Kubernetes em uma atualização das versões mais recentes do projeto, e o Pod Security Admission é o único mecanismo nativo que ficou no lugar. Times de plataforma que adiaram a migração correm risco de quebrar workloads em silêncio no próximo upgrade de cluster.

Uma remoção antiga que ainda pega gente desprevenida no upgrade de hoje

O PodSecurityPolicy (PSP) foi descontinuado e, em versões mais novas do Kubernetes, deixou de existir no control plane, como confirma a própria documentação oficial do projeto ao orientar quem está "rodando uma versão mais antiga do Kubernetes e quer atualizar para uma versão que não inclui mais PodSecurityPolicies". No lugar, a documentação oficial do projeto (kubernetes.io/docs/concepts/security/pod-security-admission) descreve o Pod Security Admission como controlador estável desde a versão 1.25.

Isso não é notícia nova, mas virou dor de cabeça atual: muitos clusters de produção no Brasil rodaram anos em versões antigas, sustentados por fornecedores de nuvem gerenciada, e só agora estão sendo forçados a atualizar porque essas versões saíram de suporte. Quando o upgrade acontece, o PSP simplesmente não existe mais no control plane, e qualquer manifesto ou automação que ainda dependia dele falha sem aviso claro.

A diferença de modelo é o que mais pega equipes de plataforma desprevenidas. PSP era um recurso cluster-wide, vinculado a ClusterRole e RoleBinding, com granularidade fina por campo de spec. Pod Security Admission trabalha em outro nível: ele aplica um dos três perfis padronizados (privileged, baseline, restricted) por namespace, via labels. Não existe política customizada nativa; quem precisava de regras mais específicas do que os três perfis definidos pelos Pod Security Standards precisa de um admission webhook à parte, como Kyverno ou Gatekeeper.

Como o Pod Security Admission decide o que barrar

O controlador lê labels aplicadas diretamente no namespace. Cada modo de operação tem sua própria label, e um namespace pode combinar os três ao mesmo tempo:

pod-security.kubernetes.io/<MODE>: <LEVEL>
pod-security.kubernetes.io/<MODE>-version: <VERSION>

Aqui MODE é enforce, audit ou warn, e LEVEL é um dos três perfis. A label -version permite fixar a política na versão que acompanhou um minor específico do Kubernetes (por exemplo v1.37) ou usar latest, o que importa muito para quem quer atualizar o cluster sem que o comportamento de enforcement mude sozinho no mesmo upgrade.

Em resumo: só enforce bloqueia de verdade. audit e warn existem para rodar em paralelo antes de travar algo em produção, exatamente o tipo de rollout gradual que times de SRE costumam preferir a uma mudança de política de uma vez só.

A armadilha que quebra coisa em silêncio

A documentação da Kubernetes aponta um detalhe que muda o resultado prático da migração: audit e warn são aplicados tanto ao workload (Deployment, Job, StatefulSet) quanto ao Pod resultante, mas enforce só vale para o Pod gerado, nunca para o objeto do workload em si. Na prática, isso significa que um kubectl apply de um Deployment pode passar limpo, sem erro nenhum na saída do comando, e só o ReplicaSet por trás dele falhar ao tentar criar os Pods reais. Quem só olha o retorno do apply não vê o problema; quem não monitora eventos do ReplicaSet descobre a quebra só quando o pod esperado nunca aparece rodando.

Isso reforça uma regra que já vale para qualquer admission controller: não basta aplicar o label e seguir em frente. É preciso rodar primeiro em audit e warn, observar o volume de violações, e só então promover para enforce namespace por namespace. Sem esse passo intermediário, o upgrade de cluster vira um teste em produção.

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

Exemplo de migração por namespace

Um roteiro razoável para quem está saindo de PSP e indo para Pod Security Admission segue nesta ordem:

1. Levantar todos os namespaces do cluster e os workloads que rodam neles, identificando quais dependiam de bindings de PSP permissivos (privileged, hostPath, root).
2. Para cada namespace, aplicar primeiro pod-security.kubernetes.io/audit: restricted e pod-security.kubernetes.io/warn: restricted, deixando o enforce ainda em baseline ou privileged.
3. Rodar os workloads normalmente por um ciclo de deploy e revisar os eventos de auditoria e os avisos retornados pelo kubectl apply.
4. Ajustar manifestos que geram violação (remover privileged: true, montagens de hostPath desnecessárias, capacidades extras) ou mapear o namespace como exceção deliberada.
5. Subir o enforce para o nível alvo só depois que o audit não acusar mais violação nova.

Exemções: mais rígidas, e de propósito

Pod Security Admission permite exceções por nome de usuário autenticado, por RuntimeClassName ou por namespace inteiro, mas todas precisam ser configuradas estaticamente na configuração do admission controller, não em runtime como era possível com PSP. A documentação chama atenção para um erro comum: isentar uma service account de controlador, como system:serviceaccount:kube-system:replicaset-controller, na prática isenta qualquer usuário que tenha permissão de criar o workload correspondente, porque é o controlador quem materializa o Pod. Times de segurança que replicarem exceções de PSP sem entender essa diferença acabam abrindo buraco maior do que tinham antes.

O que observar depois da virada

O kube-apiserver expõe três métricas Prometheus específicas para quem precisa auditar o comportamento do admission depois da migração: pod_security_errors_total (falhas de avaliação, que podem fazer o controlador cair no perfil restricted mais recente por segurança), pod_security_evaluations_total (volume de avaliações feitas) e pod_security_exemptions_total (quantas requisições passaram por exceção). Ligar essas métricas a um dashboard antes de promover qualquer namespace para enforce é o jeito de confirmar, com número e não com confiança, que a política nova não vai derrubar workload que importa.

Quando a migração não compensa sozinha

Pod Security Admission resolve bem o caso comum: restringir privilégio de containers por namespace com três níveis já definidos pela comunidade. Ele não resolve regra de negócio fina, como "só containers com esta imagem assinada podem rodar" ou "bloquear se o registry não for o interno". Para esse tipo de política, a saída segue sendo um admission webhook externo, Kyverno ou OPA Gatekeeper, rodando ao lado do Pod Security Admission nativo, não no lugar dele. Equipes que tentam forçar os três perfis padrão a cobrir regra de compliance específica tendem a acabar com namespaces cheios de exceção, o que anula o ganho de simplicidade que motivou a remoção do PSP.

Fonte: Documentação oficial do Kubernetes — Pod Security Admission