Kubernetes Pod Security: Standards, Admission e securityContext

Kubernetes Pod Security é a disciplina de restringir o que cada pod tem permissão para fazer, de modo que uma brecha dentro de um container não entregue o node inteiro a um atacante. É a camada em que a maior parte do hardening real de clusters ou acontece ou silenciosamente deixa de acontecer — e, desde a remoção da PodSecurityPolicy, ela se apoia em três peças que você precisa entender em conjunto: os Pod Security Standards, o Pod Security Admission e o securityContext no nível do pod. Este guia percorre as três, mostra as configurações que importam e explica como adotá-las sem quebrar as cargas de trabalho que você já roda.

Este artigo faz parte do nosso cluster de Kubernetes security. Se você ainda não protegeu o acesso e o tráfego, combine-o com nossos guias sobre Kubernetes RBAC e Kubernetes network policies.

Por que a segurança no nível do pod importa

Containers compartilham um kernel. Essa única frase explica por que a segurança de pods carrega tanto peso. Diferentemente das máquinas virtuais, containers no mesmo node são isolados por primitivas do kernel — namespaces, cgroups, capabilities, seccomp — e não por uma fronteira de hypervisor. Quando um pod recebe mais privilégio do que precisa, você está ampliando o raio de destruição de qualquer bug na sua aplicação ou em suas dependências.

A cadeia clássica de falha é assim: um atacante explora uma vulnerabilidade em um serviço exposto à web e obtém execução de código dentro do container. Se esse container roda como root, tem capabilities extras do Linux ou monta um host path, a fuga do container para o node costuma ser trivial. A partir do node, um atacante pode ler os secrets de todos os outros pods, adulterar o kubelet ou se mover lateralmente pelo cluster. Uma fuga de container, em outras palavras, é frequentemente um comprometimento de node — e um node comprometido está a um passo muito curto de um cluster comprometido.

A segurança de pods é como você torna esse passo longo e difícil. O objetivo não é confiar menos no código da sua aplicação; é assumir que ele acabará sendo comprometido e garantir que o comprometimento fique contido.

Da PodSecurityPolicy aos Pod Security Standards

Durante anos, a resposta para o hardening de pods foi a PodSecurityPolicy (PSP) — um recurso de escopo de cluster que controlava a criação de pods contra um conjunto de regras. A PSP era poderosa, mas notoriamente incômoda: seu modelo de autorização era confuso, a ordenação entre múltiplas políticas não era óbvia e era fácil trancar a si mesmo (ou suas cargas de trabalho) do lado de fora.

A PSP foi descontinuada no Kubernetes 1.21 e removida por completo na 1.25. Se você ainda tem objetos PSP espalhados por aí, eles não fazem nada em clusters modernos. A substituição é deliberadamente mais simples e dividida em dois conceitos: um conjunto de perfis padrão (os Pod Security Standards) e um mecanismo nativo de aplicação (o Pod Security Admission). Os Standards descrevem como é o certo; o Admission decide se deve permitir, avisar ou auditar um pod diante de um Standard escolhido.

Os três níveis dos Pod Security Standards

Os Pod Security Standards definem três níveis cumulativos, do mais permissivo ao mais restrito:

• Privileged — essencialmente sem restrições. Este nível permite escalações de privilégio conhecidas e destina-se a cargas de trabalho confiáveis, de estilo infraestrutura (pense em componentes de sistema ou um plugin CNI) que realmente precisam de acesso amplo. Namespaces de aplicação quase nunca deveriam rodar aqui.
• Baseline — um perfil minimamente restritivo que bloqueia as escalações mais óbvias e perigosas, mantendo-se fácil de adotar. Ele proíbe coisas como host namespaces, containers privileged e volumes hostPath, mas ainda permite rodar como root. O baseline é um piso sensato para a maioria dos namespaces de aplicação.
• Restricted — o perfil endurecido. Ele aplica as melhores práticas atuais de hardening de pods: rodar como não-root, remover todas as capabilities, desabilitar a escalação de privilégios e exigir um seccomp profile, entre outras. Este é o alvo para qualquer coisa que lide com dados sensíveis ou fique exposta a entradas não confiáveis.

O modelo mental é uma escada: tudo que o baseline bloqueia também é bloqueado pelo restricted, e muito mais. Você escolhe o nível mais alto que uma carga de trabalho consegue tolerar.

Como o Pod Security Admission aplica por namespace

O Pod Security Admission (PSA) é o admission controller — habilitado por padrão no Kubernetes atual — que aplica um Standard escolhido a um namespace. Você o configura não com um objeto de política, mas com rótulos no próprio namespace. Há três modos:

• `enforce` — pods que violam o nível são rejeitados no momento da criação.
• `audit` — as violações são permitidas, mas registradas no log de auditoria.
• `warn` — as violações são permitidas, mas retornam um aviso ao usuário que criou o pod.

Cada modo recebe um nível (privileged, baseline ou restricted) e, opcionalmente, uma versão fixada. Um namespace pode carregar os três de uma vez, que é exatamente como se adota com segurança — avisar e auditar em restricted enquanto se aplica apenas o baseline, por exemplo.

apiVersion: v1

kind: Namespace

metadata:

  name: payments

  labels:

    pod-security.kubernetes.io/enforce: baseline

    pod-security.kubernetes.io/enforce-version: latest

    pod-security.kubernetes.io/audit: restricted

    pod-security.kubernetes.io/warn: restricted

Esse único conjunto de rótulos bloqueia imediatamente os piores comportamentos (enforce: baseline), ao mesmo tempo em que informa, a cada deploy, exatamente o que você precisaria corrigir para chegar ao restricted. Observe que o PSA trabalha na granularidade de namespace — não há isenção por pod dentro de um namespace com enforcement, então projete o layout dos seus namespaces pensando em camadas de segurança.

As configurações de securityContext que de fato endurecem um pod

Os Standards e o Admission decidem quais regras se aplicam. O securityContext é onde você escreve as regras nos seus manifests. Estas são as configurações que carregam mais peso:

spec:

  securityContext:

    runAsNonRoot: true

    seccompProfile:

      type: RuntimeDefault

  containers:

    - name: app

      image: registry.example.com/app:1.4.2

      securityContext:

        allowPrivilegeEscalation: false

        readOnlyRootFilesystem: true

        privileged: false

        capabilities:

          drop: ["ALL"]

• `runAsNonRoot: true` (e um runAsUser concreto) impede que o container rode como UID 0. Só isso já derrota uma grande categoria de fugas.
• `allowPrivilegeEscalation: false` impede que um processo ganhe mais privilégios do que seu pai — por exemplo, via binários setuid.
• `readOnlyRootFilesystem: true` torna o sistema de arquivos raiz do container imutável, de modo que um atacante não consiga soltar um payload ou modificar binários. Monte um emptyDir para os poucos caminhos que genuinamente precisam ser graváveis.
• `capabilities.drop: ["ALL"]` remove todas as capabilities do Linux e obriga você a adicionar de volta apenas o que realmente precisa (raramente algo).
• `seccompProfile.type: RuntimeDefault` aplica o filtro seccomp padrão do runtime de container, bloqueando syscalls perigosas.
• `privileged: false` — um container privileged é efetivamente root no node. Quase nunca há um bom motivo para uma aplicação rodar em modo privileged.

Igualmente importantes são as coisas que você não deve definir. Evite `hostNetwork`, `hostPID` e `hostIPC`, que quebram o isolamento entre o pod e o node. Evite volumes `hostPath`, que montam diretórios do node diretamente dentro do pod. Esses são exatamente os comportamentos que os níveis baseline e restricted existem para bloquear.

Limites de recursos fazem parte da segurança de pods

Segurança não é só sobre privilégio — a disponibilidade também conta. Um pod sem limites pode consumir toda a CPU ou memória de um node e sufocar seus vizinhos, o que é uma condição de negação de serviço, quer aconteça por acidente, quer por má intenção. Sempre defina requests e limits:

resources:

  requests:

    cpu: "100m"

    memory: "128Mi"

  limits:

    cpu: "500m"

    memory: "256Mi"

Combine-os com um LimitRange e um ResourceQuota por namespace, para que até as cargas de trabalho esquecidas herdem limites sensatos.

Quando você precisa de um admission controller além do PSA

O Pod Security Admission é intencionalmente restrito em escopo: ele aplica os três Standards e nada mais. Isso cobre muita coisa, mas não consegue expressar regras específicas da organização. O PSA não consegue, por exemplo, exigir que as imagens venham apenas do seu registry, obrigar um rótulo específico, proibir a tag latest ou bloquear um caminho de mount específico enquanto permite outros.

Quando você precisa desse tipo de política customizada, recorre a um mecanismo de políticas de uso geral que se conecta ao Kubernetes como um validating admission webhook. Mecanismos de policy-as-code permitem escrever regras em uma linguagem de política dedicada, testá-las e versioná-las junto com o resto da sua infraestrutura. O padrão é deixar o PSA cuidar do enforcement padrão de baseline/restricted e adicionar um mecanismo de políticas por cima para tudo que é único no seu ambiente. Mantenha os dois complementares, em vez de duplicar os Standards em políticas customizadas.

Fazendo o rollout sem quebrar suas cargas de trabalho

O jeito mais rápido de perder a confiança da sua equipe é virar um namespace para enforce: restricted e ver metade dos deployments falharem. Adote em etapas, em vez disso:

1. Observe primeiro. Adicione os rótulos warn: restricted e audit: restricted a um namespace sem nenhum rótulo enforce. Nada quebra; você simplesmente coleta uma lista de todas as violações que suas cargas de trabalho disparam atualmente.
2. Corrija os manifests. Percorra os avisos, adicionando os campos de securityContext acima. A maioria das correções é pequena e mecânica.
3. Aplique o piso. Quando as cargas de trabalho estiverem limpas, defina enforce: baseline e depois eleve para enforce: restricted nos namespaces que suportam.
4. Defina o padrão para novos namespaces. Configure um padrão em todo o cluster para que os novos namespaces comecem pelo menos em baseline, e não completamente abertos.

Essa abordagem "auditar primeiro" faz com que a chave de enforcement seja uma formalidade quando você a aciona — as cargas de trabalho já estão em conformidade.

Shift left: escaneie os manifests no CI

Tudo que foi dito acima acontece na fronteira do cluster. O lugar mais barato para pegar um pod mal configurado é muito antes de ele chegar a um cluster — no pull request que o introduz. Manifests, Helm charts e overlays de Kustomize são código, e podem ser escaneados como código.

Conectar verificações de segurança de pods ao CI significa que um manifest que roda como root, monta um hostPath ou esquece os limites de recursos quebra o build com uma mensagem clara apontando para a linha problemática. Os desenvolvedores recebem feedback em segundos, na ferramenta que já usam, em vez de descobrir o problema quando um deploy é rejeitado — ou pior, quando não é. Este é o mesmo princípio de shift left que aplicamos ao longo de todo o restante do ciclo de vida de Kubernetes security.

Como a Rainforest ajuda

A Rainforest traz o enforcement de segurança de pods para dentro do fluxo de trabalho do desenvolvedor, em vez de acoplá-lo no final. Nosso scanning de infraestrutura como código analisa seus manifests do Kubernetes, Helm charts e Terraform exatamente para os problemas que este artigo cobre — containers rodando como root, campos de securityContext ausentes, host namespaces, flags de privileged e limites de recursos inexistentes — e os expõe diretamente nos pull requests. Nosso scanning de segurança de containers estende essa cobertura para as imagens que esses pods rodam, para que uma spec de pod endurecida não seja minada por uma imagem base vulnerável.

O resultado é uma imagem única e consistente: verificações de política no CI que espelham o que o Pod Security Admission vai aplicar no cluster, de modo que as configurações incorretas sejam pegas enquanto ainda são uma mudança de código e não ainda um incidente.

Se você quer ver como isso se encaixa no seu pipeline, agende uma demonstração e vamos analisar seus próprios manifests.