Kubernetes 1.25 estabiliza Pod Security e remove PodSecurityPolicy

O Kubernetes 1.25 chega com uma mudança de segurança que operadores não podem tratar como detalhe de release notes: PodSecurityPolicy foi removido, e Pod Security Admission passa a estável. O projeto já havia depreciado PodSecurityPolicy na versão 1.21; agora, quem ainda dependia desse recurso precisa migrar para o novo modelo ou para políticas externas de admissão.¹

A versão, chamada "Combiner", reúne 40 melhorias e continua a maturação de áreas importantes do projeto. Ephemeral Containers chegam a estável, suporte a cgroups v2 também avança para estável, o registro de imagens começa a se mover de k8s.gcr.io para registry.k8s.io, e SeccompDefault é promovido a beta. Ainda assim, a remoção do PSP é o ponto que mais tende a quebrar suposições em clusters existentes.

Adeus PodSecurityPolicy

PodSecurityPolicy sempre tentou resolver um problema real: controlar quais características um Pod pode usar antes de entrar no cluster. Privilégios, capacidades Linux, hostPath, namespaces de host, usuário root, seccomp e outros detalhes definem se uma carga de trabalho respeita limites aceitáveis. O problema é que o PSP ficou difícil de usar, difícil de explicar e difícil de evoluir sem mudanças incompatíveis.

Pod Security Admission adota uma abordagem mais clara, baseada nos níveis Pod Security Standards: privileged, baseline e restricted. Em vez de cada organização precisar entender uma matriz extensa de objetos PSP, namespaces podem receber políticas de admissão com comportamento mais previsível. Isso não cobre todos os cenários de política fina, mas estabelece um padrão nativo melhor para a maioria dos controles essenciais.

Para clusters com requisitos complexos, o novo caminho pode envolver Gatekeeper, Kyverno ou webhooks próprios. O ponto é que a responsabilidade não desaparece. Ela muda de ferramenta. Equipes que usavam PSP como última linha de defesa precisam garantir que a migração preserve o bloqueio de workloads privilegiados, montagem indevida de volumes e permissões perigosas.

Operação precisa revisar controles

A remoção de um recurso de segurança antigo é uma oportunidade para limpar exceções acumuladas. Muitos clusters cresceram com políticas copiadas, namespaces esquecidos e workloads que só funcionam porque ganharam permissões amplas demais. Migrar para Pod Security Admission força uma pergunta útil: quais aplicações realmente precisam de privilégios elevados?

O avanço de Ephemeral Containers para estável também merece atenção. Eles ajudam em troubleshooting quando kubectl exec não resolve, especialmente em imagens sem ferramentas de diagnóstico. Mas a capacidade de inserir contêineres temporários em Pods existentes precisa ser protegida por RBAC e auditoria, porque amplia o poder operacional de quem depura produção.

cgroups v2 estável indica alinhamento com distribuições Linux modernas. Para times de plataforma, isso reduz incerteza sobre hosts que já adotam a API nova do kernel. A transição de registro para registry.k8s.io, por sua vez, exige atenção de firewalls, mirrors, caches e políticas de allowlist.

Kubernetes 1.25 não é uma atualização que deva ser aplicada apenas olhando compatibilidade de APIs de aplicação. Ela mexe em governança de cluster. O caminho seguro passa por inventariar namespaces, simular Pod Security Admission em modo de auditoria, revisar workloads privilegiados, atualizar pipelines e documentar exceções. A estabilização do novo modelo é positiva, mas só entrega valor quando a migração é tratada como projeto de segurança, não como ajuste de YAML.