Kubernetes security: RBAC, network policies e pod security

1. Introdução à Segurança no Kubernetes

O Kubernetes adota um modelo de responsabilidade compartilhada. Enquanto o cluster admin gerencia a infraestrutura do plano de controle e dos nós, o desenvolvedor é responsável por configurar corretamente permissões, isolamento de rede e restrições de segurança nos pods. Ignorar essa responsabilidade expõe o cluster a vetores de ataque como escalonamento de privilégios, movimentação lateral entre serviços e exfiltração de dados.

Três pilares formam a base da segurança para desenvolvedores no Kubernetes:

  • RBAC – controla quem pode fazer o quê no cluster
  • Network Policies – controla o tráfego de rede entre pods
  • Pod Security Standards – controla o que o container pode executar

Dominar esses pilares reduz drasticamente a superfície de ataque de uma aplicação.

2. RBAC – Controle de Acesso Granular

Conceitos fundamentais

O RBAC do Kubernetes é composto por quatro objetos principais:

  • Role – define permissões dentro de um namespace específico
  • ClusterRole – define permissões em todo o cluster (nós, namespaces, CRDs)
  • RoleBinding – associa uma Role a um usuário/grupo/ServiceAccount dentro de um namespace
  • ClusterRoleBinding – associa uma ClusterRole a um sujeito em todo o cluster

Princípio do menor privilégio

Um desenvolvedor raramente precisa de acesso total ao cluster. Crie permissões mínimas para cada ServiceAccount:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app-dev
  name: developer-role
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets"]
  verbs: ["get", "list", "watch", "create", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app-dev
  name: developer-binding
subjects:
- kind: ServiceAccount
  name: dev-sa
  namespace: app-dev
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

Boas práticas e armadilhas comuns

  • Evite cluster-admin para desenvolvedores. Crie ClusterRoles específicas com aggregationRule se necessário.
  • Audite permissões com kubectl auth can-i --list --as=system:serviceaccount:app-dev:dev-sa
  • Nunca use * nos verbs sem avaliar o impacto. Prefira listas explícitas.

3. Network Policies – Isolamento de Tráfego entre Pods

Como as Network Policies funcionam

Network Policies são recursos namespaced que usam seletores de pods e namespaces para definir regras de tráfego de entrada (ingress) e saída (egress). O comportamento padrão do Kubernetes é permitir todo o tráfego – a política inverte essa lógica.

Exemplo prático

Considere uma aplicação com frontend, backend e banco de dados. A política abaixo permite apenas tráfego do frontend para o backend e do backend para o banco:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
  namespace: app-prod
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - port: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-allow-backend
  namespace: app-prod
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - port: 5432

Desafios comuns

  • Dependência de CNI: políticas só funcionam com plugins de rede como Calico, Cilium ou Weave.
  • Default deny: crie uma política que negue todo o tráfego por padrão e depois libere o necessário.
  • Troubleshooting: use kubectl run -it --image=nicolaka/netshoot e comandos como nc -zv para testar conectividade.

4. Pod Security Standards (PSS) e Pod Security Admission (PSA)

Os três níveis de segurança

O Kubernetes define três níveis de segurança para pods:

  • Privileged – sem restrições (uso interno para workloads do sistema)
  • Baseline – restrições mínimas, evita escalonamento de privilégio conhecido
  • Restricted – máximo de restrições, alinhado com boas práticas de container

Migração de PSP para PSA

O PodSecurityPolicy (PSP) foi removido no Kubernetes 1.25. O Pod Security Admission (PSA) é o substituto, ativado por labels nos namespaces:

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

Exemplo de configuração

Workloads no namespace app-restricted precisam atender ao nível Restricted:

apiVersion: v1
kind: Pod
metadata:
  name: web-server
  namespace: app-restricted
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: nginx
    image: nginx:1.25
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
      readOnlyRootFilesystem: true

Se o pod tentar rodar como root, o PSA rejeitará a criação.

5. Integração entre RBAC, Network Policies e Pod Security

Cenário real

Uma aplicação web com banco de dados PostgreSQL. As três camadas atuam juntas:

  1. RBAC: ServiceAccount web-sa tem permissão apenas para ler ConfigMaps e Secrets no namespace
  2. Network Policy: frontend só fala com backend na porta 8080; backend só fala com banco na porta 5432
  3. Pod Security: todos os pods rodam com restricted – sem root, sem escalonamento, filesystem read-only

Exemplo de manifesto combinado

apiVersion: v1
kind: ServiceAccount
metadata:
  name: web-sa
  namespace: app-prod
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app-prod
  name: web-role
rules:
- apiGroups: [""]
  resources: ["configmaps", "secrets"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app-prod
  name: web-binding
subjects:
- kind: ServiceAccount
  name: web-sa
roleRef:
  kind: Role
  name: web-role
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: app-prod
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      serviceAccountName: web-sa
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: web
        image: myapp:1.0
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: ["ALL"]
          readOnlyRootFilesystem: true

A Network Policy correspondente isola o tráfego e o PSA do namespace garante que nenhum pod fuja das restrições.

6. Ferramentas e Boas Práticas para Desenvolvedores

Ferramentas de validação

  • kubectl dry-run: kubectl apply -f manifest.yaml --dry-run=server valida no cluster sem aplicar
  • kube-score: analisa manifestos contra boas práticas de segurança
  • Polaris: valida workloads contra regras de segurança configuráveis
  • kube-bench: verifica se o cluster segue o CIS Benchmark

Checklist de segurança para deploy

  • [ ] ServiceAccount com permissões mínimas
  • [ ] securityContext com runAsNonRoot: true e readOnlyRootFilesystem: true
  • [ ] capabilities.drop: ["ALL"] e allowPrivilegeEscalation: false
  • [ ] Network Policies definidas para cada serviço
  • [ ] Namespace com label PSA enforce: restricted

Integração com CI/CD

Use ferramentas como Trivy e kubeconform para escanear manifestos antes do deploy:

# Exemplo de comando para CI
trivy config --severity HIGH,CRITICAL k8s-manifests/
kubeconform -strict -summary k8s-manifests/

7. Conclusão e Próximos Passos

RBAC, Network Policies e Pod Security Standards formam a tríade de segurança que todo desenvolvedor precisa dominar no Kubernetes. RBAC controla quem faz o quê, Network Policies isola o tráfego e Pod Security restringe o comportamento dos containers. Juntas, essas camadas reduzem drasticamente a superfície de ataque e previnem movimentação lateral.

Para aprofundar, explore tópicos como gerenciamento de Secrets, hardening de containers e segurança em pipelines CI/CD. A documentação oficial do Kubernetes e os guias de hardening do NSA são leituras obrigatórias.

Referências