Kubernetes Pod Security Standards com Kyverno: Migração da PSP

Por que PSP foi removida

PodSecurityPolicy foi a primeira tentativa do Kubernetes de impor controles de segurança em pods (privilégios, hostPath, capabilities). Foi deprecada em 1.21 (abril/2021) e removida em 1.25 (agosto/2022). Por quê? PSP tinha três problemas operacionais sérios: (1) ordem de avaliação imprevisível quando havia várias políticas, (2) RBAC complexo — você precisava conceder use da PSP ao service account, com efeitos colaterais perversos, (3) sem mutação fácil para corrigir manifests, só rejeitar.

A substituição nativa é Pod Security Standards (PSS), que padroniza três perfis simples aplicados por namespace, sem RBAC custom. Para tudo que PSS não cobre — regras específicas da organização, mutações, validações ricas — entra um policy engine como Kyverno (ou OPA Gatekeeper). Esta é a combinação dominante em 2026.

Pod Security Standards: 3 perfis

PSS define três níveis cumulativos, em ordem de restrição crescente:

Modos audit, warn e enforce

Cada perfil pode ser aplicado em três modos via labels no namespace. Eles podem coexistir com versões diferentes do perfil:

apiVersion: v1
kind: Namespace
metadata:
  name: payments-api
  labels:
    # Bloqueia pods que violam baseline
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.29
    # Avisa no kubectl apply se viola restricted (não bloqueia)
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.29
    # Registra violações de restricted no audit log
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.29

Padrão de adoção:

• Fase 1: audit + warn em todos os namespaces. Observe o audit log por 1-2 semanas.
• Fase 2: enforce baseline. Pods que violam baseline são rejeitados.
• Fase 3: enforce restricted onde for possível. Workloads legados ficam em baseline.

Exemplo baseline na prática

Considere um Pod que tenta rodar com privilégios elevados:

apiVersion: v1
kind: Pod
metadata:
  name: legacy-app
  namespace: payments-api
spec:
  hostNetwork: true        # <- bloqueado em baseline
  containers:
  - name: app
    image: corp/app:1.2.3
    securityContext:
      privileged: true     # <- bloqueado em baseline
      capabilities:
        add: [ "SYS_ADMIN" ]  # <- bloqueado em baseline

Com enforce=baseline no namespace, o API server rejeita imediatamente:

Error from server (Forbidden): error when creating "legacy-app.yaml":
pods "legacy-app" is forbidden: violates PodSecurity "baseline:v1.29":
  host namespaces (hostNetwork=true),
  privileged (container "app" must not set securityContext.privileged=true),
  non-default capabilities (container "app" must not include "SYS_ADMIN" in securityContext.capabilities.add)

Exemplo restricted

Um Pod que passa em restricted típico:

apiVersion: v1
kind: Pod
metadata:
  name: api
  namespace: payments-api
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 10001
    runAsGroup: 10001
    fsGroup: 10001
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: api
    image: corp/api:2.0.0
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: [ "ALL" ]
    volumeMounts:
    - name: cache
      mountPath: /tmp
  volumes:
  - name: cache
    emptyDir: {}

Note que readOnlyRootFilesystem: true exige montar volumes emptyDir/PVC para qualquer escrita (tmp, cache, logs).

Quando entra o Kyverno

PSS resolve o piso de segurança comum. Kyverno entra em três cenários:

Exemplo de ClusterPolicy Kyverno que exige imagens vindas apenas do registry corporativo:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-corp-registry
spec:
  validationFailureAction: Enforce
  background: true
  rules:
  - name: validate-image-registry
    match:
      any:
      - resources:
          kinds: [Pod]
          namespaces: ["payments-*", "billing-*"]
    validate:
      message: "Imagens devem vir de registry.corp.example.com"
      pattern:
        spec:
          containers:
          - image: "registry.corp.example.com/*"

Para combinar com SLSA/Cosign (ver artigo dedicado):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-signature
    match:
      any:
      - resources:
          kinds: [Pod]
    verifyImages:
    - imageReferences:
      - "registry.corp.example.com/*"
      attestors:
      - entries:
        - keyless:
            subject: "https://github.com/corp/*/.github/workflows/release.yml@refs/heads/main"
            issuer: "https://token.actions.githubusercontent.com"

Troubleshooting comum

Roadmap de migração

Para clusters que ainda dependem de PSP ou estão sem qualquer admission de segurança:

Perguntas frequentes

Referências