Pod Security Standards: substituindo PodSecurityPolicy

1. Contexto e Motivação: Por que substituir o PodSecurityPolicy?

O PodSecurityPolicy (PSP) foi introduzido no Kubernetes 1.4 como uma solução para controlar permissões de segurança dos Pods. No entanto, sua implementação trouxe diversos desafios. A complexidade de criação e manutenção de políticas, a falta de clareza nos modos de enforcement e a dificuldade de adoção por equipes DevOps levaram a uma baixa taxa de adoção na comunidade.

No Kubernetes 1.21, o PSP foi oficialmente depreciado, e no 1.25, removido completamente. A substituição veio com os Pod Security Standards (PSS), uma abordagem mais simples, nativa e alinhada com as necessidades modernas de segurança em clusters Kubernetes.

2. Entendendo os Pod Security Standards (PSS)

Os PSS definem três níveis de segurança cumulativos:

  • Privileged: Sem restrições. Permite execução de containers com privilégios totais, acesso a hostNetwork, hostPID, volumes hostPath e qualquer configuração de segurança.
  • Baseline: Restrições mínimas. Impede escalonamento de privilégios (allowPrivilegeEscalation: false), proíbe privileged: true, mas permite NET_RAW, hostNetwork e hostPath com controle.
  • Restricted: Máximo de segurança. Exige runAsNonRoot: true, seccompProfile, readOnlyRootFilesystem, proíbe hostNetwork, hostPID, hostIPC e limita capabilities.

O mapeamento de políticas comuns é direto:
- privileged: true → apenas Privileged
- hostNetwork: true → Baseline ou Privileged
- runAsNonRoot: true → Restricted ou Baseline com exceções

3. Implementando PSS com Pod Security Admission (PSA)

O Pod Security Admission controller é nativo no Kubernetes 1.23+. Ele opera em três modos:

  • enforce: Bloqueia pods que violam a política
  • audit: Registra violações nos logs sem bloquear
  • warn: Exibe avisos ao usuário sem bloquear

Exemplo de ativação via labels no namespace:

apiVersion: v1
kind: Namespace
metadata:
  name: producao-restrito
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

4. Estratégias de Migração de PSP para PSS

A migração deve ser gradual e baseada em auditoria:

  1. Auditoria inicial: Mapeie todos os PSPs existentes para os níveis PSS correspondentes. Ferramentas como psp-migrator (kubectl-plugin) ajudam a converter regras.
  2. Modo warn/audit: Aplique labels warn: baseline e audit: restricted em namespaces existentes. Monitore logs por 1-2 semanas.
  3. Aplicação gradual: Comece com namespaces não críticos, depois avance para produção.

Exemplo de análise de logs de auditoria:

# Verificar violações registradas
kubectl get events --all-namespaces | grep -i "podsecurity"
kubectl logs -n kube-system kube-apiserver-* | grep "PodSecurity"

5. Exemplos Práticos com Docker e Kubernetes

Cenário 1: Aplicação Restritiva (Restricted)

apiVersion: v1
kind: Pod
metadata:
  name: nginx-restrito
  namespace: producao-restrito
spec:
  containers:
  - name: nginx
    image: nginx:latest
    securityContext:
      runAsNonRoot: true
      runAsUser: 101
      seccompProfile:
        type: RuntimeDefault
      capabilities:
        drop: ["ALL"]
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true

Cenário 2: Aplicação Legada (Baseline)

apiVersion: v1
kind: Pod
metadata:
  name: app-legado
  namespace: legado
spec:
  containers:
  - name: app
    image: minhaapp:1.0
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add: ["NET_RAW"]
        drop: ["ALL"]
  hostNetwork: false

Cenário 3: Infraestrutura Privilegiada (Privileged)

apiVersion: v1
kind: Pod
metadata:
  name: kube-proxy
  namespace: kube-system
spec:
  containers:
  - name: kube-proxy
    image: k8s.gcr.io/kube-proxy:v1.28
    securityContext:
      privileged: true
  hostNetwork: true
  hostPID: true

6. Customizando com Admission Controllers e OPA/Gatekeeper

O PSA nativo não oferece granularidade fina para exceções complexas. Para cenários avançados, combine com OPA/Gatekeeper ou Kyverno.

Exemplo de constraint OPA replicando Restricted com exceção para NET_RAW:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPAllowPrivilegeEscalationContainer
metadata:
  name: psp-allow-privilege-escalation
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    excludedNamespaces:
      - kube-system
  parameters:
    exemptImages:
      - "myregistry.com/legacy-app:*"

7. Boas Práticas DevOps e Governança

Integre validação de segurança no pipeline CI/CD:

# Exemplo de verificação com kube-score
kube-score score deployment.yaml

# Exemplo com polaris
polaris audit --namespace producao-restrito

Para monitoramento contínuo, configure alertas no Prometheus:

# Alerta para violações de PSS
- alert: PodSecurityViolation
  expr: rate(kube_pod_security_violations_total[5m]) > 0
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "Pod security violation detected"

Documente os padrões de segurança em um repositório centralizado e realize treinamentos periódicos com a equipe.

8. Considerações Finais e Próximos Passos

O PSS oferece vantagens significativas sobre o PSP: simplicidade de configuração, manutenção reduzida e escalabilidade nativa. A migração é essencial para clusters Kubernetes modernos.

Para aprofundamento, explore temas vizinhos como:
- External Secrets para gerenciamento seguro de credenciais
- Network Policies para isolamento de tráfego
- Resource Quotas para governança de recursos

Checklist para adoção completa:
- [ ] Auditoria de namespaces e cargas de trabalho
- [ ] Aplicação de labels PSS em modo warn/audit
- [ ] Correção de pods que violam políticas
- [ ] Ativação do modo enforce em namespaces não críticos
- [ ] Configuração de exceções com OPA/Gatekeeper
- [ ] Integração com CI/CD e monitoramento

Referências