Pod Security Admission é o caminho oficial para aposentar o PodSecurityPolicy no Kubernetes

PodSecurityPolicy foi descontinuado pelo 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 →, mas muitos clusters ainda rodam sem nenhum controle de admissão de segurança no lugar. A documentação oficial detalha como o Pod Security Admission resolve isso por namespace, sem exigir um webhook externo.

PodSecurityPolicy (PSP) foi descontinuado pelo projeto Kubernetes rumo a um substituto nativo. De lá para cá, qualquer cluster que não tenha migrado para um substituto está rodando sem nenhum controle de admissão de segurança sobre contêiner privilegiado, hostPath, hostNetwork ou escalonamento de privilégio. Isso não é teórico: é a diferença entre um pod comprometido ficar isolado ou virar acesso root ao nó.

A resposta oficial do projeto é o Pod Security Admission (PSA), estável desde a versão 1.25 e descrito em detalhe na documentação do Kubernetes. Diferente do PSP, que exigia uma PodSecurityPolicy global e um RBAC complexo para vincular política a usuário, o PSA aplica a Pod Security Standards direto por namespace, via label. Não precisa instalar nada: o admission controller já vem embutido no kube-apiserver.

Os três níveis e como eles se aplicam

O PSA trabalha com três perfis definidos pelos Pod Security Standards:

• privileged: sem restrição, equivalente a não ter política nenhuma.
• baseline: bloqueia as escalações conhecidas (containers privilegiados, hostNetwork, hostPID, capacidades perigosas), mas não exige hardening fino.
• restricted: aplica as melhores práticas de hardening, incluindo runAsNonRoot, seccompProfile obrigatório e allowPrivilegeEscalation: false.

A escolha de nível não é binária por cluster: é por namespace, e cada namespace pode combinar os três modos de aplicação ao mesmo tempo.

Os três modos: enforce, audit, warn

O documento do Kubernetes deixa claro que nível e modo são conceitos separados. O modo decide o que acontece quando um pod viola a política escolhida:

Essa separação é o que torna a migração segura. Em vez de aplicar restricted em enforce direto e quebrar todo deploy que violar a política, dá para rodar warn e audit primeiro, medir o impacto real nos logs e só então apertar o enforce.

Como configurar por namespace

A configuração é feita via label no objeto Namespace, no formato pod-security.kubernetes.io/<modo>: <nível>. Um namespace de produção em transição ficaria assim:

apiVersion: v1
kind: Namespace
metadata:
  name: pagamentos
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/audit: restricted

Na prática isso significa: nada abaixo de baseline sobe (contêiner privilegiado é barrado de verdade), mas qualquer coisa que violaria restricted gera aviso e entra no log de auditoria sem derrubar o deploy. Esse é o estado intermediário recomendado para quem está migrando de PSP: trava o óbvio, mede o resto.

O detalhe que quebra deploy sem avisar

Existe uma pegadinha documentada que todo time de plataforma precisa saber antes de apertar o enforce: workloads como Deployment e Job recebem audit e warn, mas não recebem enforce diretamente. O enforce só age sobre o objeto Pod final, criado pelo controller do workload.

Na prática, isso quer dizer que um kubectl apply num Deployment problemático tende a passar sem erro imediato: a rejeição só acontece quando o ReplicaSet tenta criar o Pod final, não no momento do apply do Deployment. Por isso, vale verificar os eventos do Pod e do ReplicaSet gerados antes de assumir que um deploy travado tem outra causa.

Versionamento: congelar a política contra novas versões do Kubernetes

Outro ponto que o PSP nunca resolveu bem é a estabilidade da política entre upgrades de cluster. O PSA tem um label específico para isso, pod-security.kubernetes.io/<modo>-version, que fixa a definição do nível numa versão minor específica (por exemplo, v1.28) em vez de seguir sempre a mais recente.

Isso importa porque é razoável supor que os Pod Security Standards continuem evoluindo entre minor releases, o que torna prudente não depender sempre da versão mais recente sem revisão prévia. Sem o pin de versão, um upgrade de cluster pode endurecer silenciosamente o restricted já em produção e rejeitar pods que antes passavam. Fixar a versão dá controle sobre quando essa régua sobe, desacoplando o ciclo de upgrade do Kubernetes do ciclo de revisão de política de segurança.

Exceções: quando algo legítimo precisa furar a regra

A documentação também prevê exemptions configuradas estaticamente no admission controller, por três dimensões: nome de usuário, RuntimeClassName ou namespace inteiro. É o mecanismo certo para, por exemplo, liberar um operador de monitoramento que precisa de hostPID sem abaixar o nível de todo o namespace.

Um cuidado citado explicitamente: isentar uma service account de controller (como system:serviceaccount:kube-system:replicaset-controller) isenta, por tabela, qualquer usuário que tenha permissão de criar o workload correspondente. Isso anula a política para esse recurso inteiro, não só para o caso pontual que motivou a exceção.

Observabilidade: três métricas para acompanhar a migração

O kube-apiserver expõe três métricas Prometheus específicas para isso: pod_security_evaluations_total (quantas avaliações de política rodaram), pod_security_exemptions_total (quantas requisições foram isentas) e pod_security_errors_total (erros que impediram a avaliação normal, que fazem o controller cair para o perfil restricted mais recente por segurança).

Acompanhar pod_security_evaluations_total é a forma de medir, antes de trocar warn/audit por enforce, quantos pods realmente violariam a política nova. Sem esse número, apertar a trava é aposta, não decisão.

Onde não vale forçar restricted imediatamente

restricted é o nível certo para workloads novos e para serviços que já rodam sem privilégio especial. Mas cargas legadas com hostPath para log local, agentes de nó que precisam de hostNetwork ou jobs de backup que montam volume de host raramente passam em restricted sem reescrita. Forçar isso de uma vez quebra exatamente o tipo de carga que mais precisa estar no ar.

O caminho mais seguro, para quem ainda tem PSP ou nenhuma política em produção, é: baseline em enforce primeiro (fecha a brecha grave de contêiner privilegiado), restricted em warn/audit em paralelo, e só promover namespace por namespace para enforce: restricted depois de zerar as violações nas métricas. É mais lento que um corte seco, mas é o que separa migração de incidente.

Fonte 1: Documentação oficial do Kubernetes — Pod Security Admission (https://kubernetes.io/docs/concepts/security/pod-security-admission/)

Pod Security Admission | Kubernetes

Pod Security Admission An overview of the Pod Security Admission Controller, which can enforce the Pod Security Standards. Feature state: Stable since Kubernetes v1.25 The Kubernetes Pod Security Standards define different isolation levels for Pods. These standards let you define how you want to restrict the behavior of pods in a clear, consistent fashion. Kubernetes offers a built-in Pod Security admission controller to enforce the Pod Security Standards.

Pod security restrictions are applied at the namespace level when pods are created. Built-in Pod Security admission enforcement This page is part of the documentation for Kubernetes v1.37. If you are running a different version of Kubernetes, consult the documentation for that release. Pod Security levels Pod Security admission places requirements on a Pod's Security Context and other related fields according to the three levels defined by the Pod Security Standards : privileged , baseline , and restricted .

Refer to the Pod Security Standards page for an in-depth look at those requirements. Pod Security Admission labels for namespaces Once the feature is enabled or the webhook is installed, you can configure namespaces to define the admission control mode you want to use for pod security in each namespace. Kubernetes defines a set of labels that you can set to define which of the predefined Pod Security Standard levels you want to use for a namespace.

The label you select defines what action the control plane takes if a potential violation is detected: Pod Security Admission modes Mode Description enforce Policy violations will cause the pod to be rejected. audit Policy violations will trigger the addition of an audit annotation to the event recorded in the audit log , but are otherwise allowed. warn Policy violations will trigger a user-facing warning, but are otherwise allowed. A namespace can configure any or all modes, or even set a different level for different modes. For each mode, there are two labels that determine the policy used: # The per-mode level label indicates which policy level to apply for the mode. # # MODE must be one of enforce, audit, or warn. # LEVEL must be one of privileged, baseline, or restricted. pod-security.kubernetes.io/ :

# Optional: per-mode version label that can be used to pin the policy to the # version that shipped with a given Kubernetes minor version (for example v1.37). # VERSION must be a valid Kubernetes minor version, or latest. pod-security.kubernetes.io/-version :

Check out Enforce Pod Security Standards with Namespace Labels to see example usage. Workload resources and Pod templates Pods are often created indirectly, by creating a workload object such as a Deployment or Job . The workload object defines a Pod template and a controller for the workload resource creates Pods based on that template. To help catch violations early, both the audit and warning modes are applied to the workload resources. However, enforce mode is not applied to workload resources, only to the resulting pod objects.

Exemptions You can define exemptions from pod security enforcement in order to allow the creation of pods that would have otherwise been prohibited due to the policy associated with a given namespace. Exemptions can be statically configured in the Admission Controller configuration . Exemptions must be explicitly enumerated. Requests meeting exemption criteria are ignored by the Admission Controller (all enforce , audit and warn behaviors are skipped). Exemption dimensions include: Usernames: requests from users with an exempt authenticated (or impersonated) username are ignored.

RuntimeClassNames: pods and workload resources specifying an exempt runtime class name are Namespaces: pods and workload resources in an exempt namespace are ignored. Caution: Most pods are created by a controller in response to a workload resource , meaning that exempting an end user will only exempt them from enforcement when creating pods directly, but not when creating a workload resource. Controller service accounts (such as system:serviceaccount:kube-system:replicaset-controller ) should generally not be exempted, as doing so would implicitly exempt any user that can create the corresponding workload resource.

Updates to the following pod fields are exempt from policy checks, meaning that if a pod update request only changes these fields, it will not be denied even if the pod is in violation of the current policy level: Any metadata updates except changes to the seccomp or AppArmor annotations: seccomp.security.alpha.kubernetes.io/pod (deprecated) container.seccomp.security.alpha.kubernetes.io/ (deprecated) container.apparmor.security.beta.kubernetes.io/ (deprecated) Valid updates to .spec.activeDeadlineSeconds Valid updates to .spec.tolerations Metrics Here are the Prometheus metrics exposed by kube-apiserver: pod_security_errors_total : This metric indicates the number of errors preventing normal evaluation.

Non-fatal errors may result in the latest restricted profile being used for enforcement. pod_security_evaluations_total : This metric indicates the number of policy evaluations that have occurred, not counting ignored or exempt requests during exporting. pod_security_exemptions_total : This metric indicates the number of exempt requests, not counting ignored or out of scope requests.

What's next Pod Security Standards Enforcing Pod Security Standards Enforce Pod Security Standards by Configuring the Built-in Admission Controller Enforce Pod Security Standards with Namespace Labels If you are running an older version of Kubernetes and want to upgrade to a version of Kubernetes that does not include PodSecurityPolicies, read migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller . Feedback Was this page helpful?

Yes No Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow . Open an issue in the GitHub Repository if you want to report a problem or suggest an improvement . Last modified March 07, 2024 at 4:54 PM PST: AppArmor v1.30 docs update (4f11f83a45)

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