APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Pod Security Admission distingue warn, audit e enforce. Um aviso ajuda a preparar uma migração, mas não rejeita por si um Pod. Enforce atua sobre os Pods resultantes; um Deployment aceite pode continuar sem réplicas porque o controlador não consegue criar Pods compatíveis. Consulta eventos antes de investigar probes ou rede. Fixa a versão da política quando precisas de uma referência controlada, por exemplo Restricted v1.35, e planeia a atualização dessa referência. Nos exemplos Linux deste percurso, revê também initContainers e outros containers relevantes, para que a revisão não se limite à aplicação principal.
Aplicação guiada
Um contexto de segurança deve corresponder ao comportamento da aplicação. Correr sem root, impedir escalada e reduzir capabilities são decisões que precisam de validação funcional. Um filesystem raiz só de leitura pode exigir um volume temporário em /tmp; isso não justifica tornar toda a imagem gravável. Antes da janela de produção, ensaia o template completo com a mesma política e confirma a transação de negócio, não apenas a criação do objeto. Se um initContainer viola a política, corrige a necessidade concreta ou usa uma versão anterior compatível. Uma exceção ampla no namespace pode afetar aplicações que não participaram na decisão, pelo que precisa de avaliação de âmbito, prazo e responsável.
O Deployment existe mas os eventos indicam allowPrivilegeEscalation no initContainer: corrige esse template e observa a admissão dos novos Pods.
Armadilhas comuns
Warn como bloqueio; Deployment aceite como release concluída; olhar apenas para o container principal; remover enforce por conveniência.
Tópicos relacionados: Segredos, cifragem e recuperação · Artefactos, proveniência e vulnerabilidades
Política, template e comportamento funcional precisam de ser validados em conjunto.
Referência: Pod Security Admission · Kubernetes v1.35; current six-domain CKS outline