Guia Completo de CIS Benchmark para Kubernetes: Hardening e Auditoria de Cluster Já leu

O que é CIS Benchmark para Kubernetes

O CIS Benchmark (Center for Internet Security) é um conjunto de diretrizes de segurança criadas pela comunidade que definem o estado ideal de configuração para sistemas. Para Kubernetes, ele funciona como um padrão de referência que lista recomendações de segurança organizadas em controles específicos. Esses controles cobrem desde configurações de componentes do cluster até políticas de rede e gerenciamento de identidades, ajudando você a fechar brechas de segurança antes que se tornem vulnerabilidades críticas.

O CIS Benchmark não é uma ferramenta mágica que você instala e pronto. É um framework conceitual: um checklist estruturado com centenas de verificações que seu cluster deve passar. Você precisa entender cada recomendação, avaliar o risco, e implementar conforme sua realidade operacional. Algumas verificações são críticas (como RBAC apropriado), outras são recomendações de endurecimento (como adicionar contextos de segurança). A importância disso é que Kubernetes é complexo, e um cluster inseguro pode expor sua infraestrutura inteira.

Pilares Principais do CIS Benchmark para Kubernetes

Controle de Acesso e Autenticação (RBAC)

O RBAC (Role-Based Access Control) é o primeiro pilar de defesa. O CIS Benchmark exige que você implemente controles granulares para definir quem pode fazer o quê no cluster. Isso significa criar Roles e ClusterRoles específicas, binding usuarios ou service accounts a essas roles, e nunca usar credenciais admin para aplicações.

Uma falha comum é manter o usuário padrão do cluster com permissões excessivas ou permitir que qualquer pod acesse a API do Kubernetes sem restrição. O benchmark recomenda criar service accounts dedicadas por aplicação e atribuir apenas as permissões necessárias. Veja na prática:

# Definir uma Role que permite apenas read em pods
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
# Criar um ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: production
---
# Bind da Role ao ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: pod-reader
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: production

Depois, use esse service account em seu Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
  namespace: production
spec:
  replicas: 1
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      serviceAccountName: app-sa
      containers:
      - name: app
        image: myapp:1.0
        resources:
          limits:
            memory: "256Mi"
            cpu: "250m"

A auditoria dessa configuração envolve verificar se há ClusterRoleBindings globais desnecessárias, se contas de serviço padrão estão sendo usadas, e se há permissões wildcards (*) em rules, que devem ser evitadas.

Políticas de Segurança de Pod (Pod Security Policy / Pod Security Standards)

O Kubernetes não executa pods com permissões restritas por padrão. Um container pode rodar como root, usar volumes privilegiados, ou acessar o filesystem do host. O CIS Benchmark exige que você implemente políticas que forçam padrões de segurança mínimos. Nas versões recentes, isso é feito via Pod Security Standards (PSS), que substituiu Pod Security Policy (PSP).

Pod Security Standards define três níveis: Restricted (mais seguro), Baseline (compatibilidade básica), e Privileged (sem restrições). Para comply com CIS, você deve aplicar Restricted em namespaces críticos. Aqui está como habilitar isso:

# Aplicar PSS em um namespace usando labels
apiVersion: v1
kind: Namespace
metadata:
  name: secure-app
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

E uma definição de pod que atende ao padrão Restricted:

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
  namespace: secure-app
spec:
  containers:
  - name: app
    image: myapp:1.0
    securityContext:
      # Não rodar como root
      runAsNonRoot: true
      runAsUser: 1000
      # Filesystem read-only
      readOnlyRootFilesystem: true
      # Nenhuma capability Linux
      capabilities:
        drop:
        - ALL
      # Não permitir escalonamento de privilégio
      allowPrivilegeEscalation: false
    volumeMounts:
    - name: tmp
      mountPath: /tmp
  # Proibir volumes hostPath e privilegiados no nível do pod
  securityContext:
    fsGroup: 2000
  volumes:
  - name: tmp
    emptyDir: {}

Isso garante que o container roda com privilégios mínimos. Se sua aplicação realmente precisa de mais permissões, documente por que e implemente exceções controladas.

Auditoria e Logging

Auditoria significa registrar o que acontece no seu cluster. O CIS Benchmark requer que você habilite audit logging na API do Kubernetes, capture eventos importantes (como mudanças em RBAC, secrets, ou configurações sensíveis), e retenha esses logs por tempo suficiente para investigação de incidentes.

A auditoria funciona interceptando requisições à API e registrando o que foi solicitado, quem solicitou, e qual foi o resultado. Você configura isso no arquivo de politica de auditoria do kube-apiserver. Exemplo de política audit básica conforme o CIS recomenda:

apiVersion: audit.k8s.io/v1
kind: Policy
# Log all requests at the RequestResponse level
rules:
  # Log pod exec at RequestResponse level
  - level: RequestResponse
    verbs: ["create"]
    resources: ["pods/exec"]

  # Log all changes to secrets
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources: ["secrets"]

  # Log RBAC changes
  - level: RequestResponse
    verbs: ["create", "update", "patch", "delete"]
    resources: ["roles", "rolebindings", "clusterroles", "clusterrolebindings"]

  # Log everything else at Metadata level
  - level: Metadata

Você aplica isso adicionando flags ao kube-apiserver:

kube-apiserver \
  --audit-policy-file=/etc/kubernetes/audit-policy.yaml \
  --audit-log-path=/var/log/kubernetes/audit/audit.log \
  --audit-log-maxage=30 \
  --audit-log-maxbackup=10 \
  --audit-log-maxsize=100

Depois, integre esses logs em um sistema de monitoramento centralizado (ELK, Splunk, etc.) para detectar padrões anormais automaticamente.

Verificação Prática: Ferramentas de Auditoria

kube-bench: Automatizando Verificações CIS

Em vez de auditar manualmente cada controle, use o kube-bench, que é a ferramenta oficial do CIS para validar clusters Kubernetes. Ele automatiza todas as verificações e gera um relatório detalhado.

Instale e execute em seu cluster:

# Instalar kube-bench
curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.7.0/kube-bench_linux_x86_64.tar.gz | tar -xz
sudo mv kube-bench /usr/local/bin/

# Executar a auditoria completa
kube-bench run --targets node,policies,managedservices

O kube-bench percorre todos os controles CIS e retorna algo assim:

[PASS] 1.1.1 Ensure that the --cert-file and --key-file certificate options are set appropriately
[FAIL] 1.2.1 Ensure that client certificate authentication is used for kubelet connections
[WARN] 1.3.1 Ensure that the controller manager pod specification file permissions are set to 644 or more restrictive

Cada falha (FAIL) deve ser tratada. O significado de WARN depende de sua arquitetura—às vezes é negligenciável, outras vezes crítico. Você pode rodá-lo periodicamente em CI/CD para garantir compliance contínuo:

# Pipeline CI/CD exemplo
apiVersion: batch/v1
kind: CronJob
metadata:
  name: kube-bench-audit
  namespace: security
spec:
  schedule: "0 2 * * 0"  # Toda segunda-feira às 2 AM
  jobTemplate:
    spec:
      template:
        spec:
          serviceAccountName: kube-bench-sa
          containers:
          - name: kube-bench
            image: aquasec/kube-bench:v0.7.0
            command: ["kube-bench", "run", "--targets", "node,policies"]
            volumeMounts:
            - name: var-lib-kubelet
              mountPath: /var/lib/kubelet
            - name: etc-kubernetes
              mountPath: /etc/kubernetes
          volumes:
          - name: var-lib-kubelet
            hostPath:
              path: /var/lib/kubelet
          - name: etc-kubernetes
            hostPath:
              path: /etc/kubernetes
          restartPolicy: Never

Verificação Manual de Controles Críticos

Algumas verificações você deve fazer manualmente ou via scripts custom. Aqui está um exemplo de script que valida controles essenciais:

#!/bin/bash
# Script de auditoria CIS Kubernetes

echo "=== Verificação de Hardening Kubernetes ==="

# 1. Verificar se RBAC está habilitado
echo -e "\n[1] Verificando RBAC..."
if kubectl api-resources | grep -q roles.rbac; then
    echo "✓ RBAC habilitado"
else
    echo "✗ RBAC não detectado"
fi

# 2. Verificar service accounts padrão
echo -e "\n[2] Verificando service accounts com excesso de permissão..."
kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects[] | select(.kind=="ServiceAccount")'

# 3. Verificar Pods Security Policy
echo -e "\n[3] Verificando PSP/PSS..."
kubectl get psp 2>/dev/null && echo "PSP encontrado" || echo "Usando Pod Security Standards"
kubectl get namespace -o json | jq '.items[] | .metadata.labels | select(. != null) | select(.["pod-security.kubernetes.io/enforce"] != null)'

# 4. Verificar audit logging
echo -e "\n[4] Verificando auditoria..."
kubectl get pods -n kube-system -o json | jq '.items[] | select(.metadata.name | contains("kube-apiserver")) | .spec.containers[] | .args[] | select(. | contains("audit"))'

# 5. Verificar network policies
echo -e "\n[5] Verificando Network Policies..."
kubectl get networkpolicies -A

Hardening Avançado: Além do Básico

Isolamento de Rede com Network Policies

O CIS Benchmark recomenda implementar network policies para controlar o tráfego entre pods. Por padrão, Kubernetes permite qualquer pod comunicar-se com qualquer outro. Network Policies funcionam como firewalls para seus containers.

Uma policy básica que nega todo tráfego por padrão e permite apenas o necessário:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
---
# Permitir tráfego específico
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-app-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: webapp
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432
  - to:
    - namespaceSelector: {}
    ports:
    - protocol: TCP
      port: 53  # DNS

Isso garante que apenas tráfego autorizado flua entre pods. Qualquer requisição não explicitamente permitida é bloqueada.

Gerenciamento de Secrets

Secrets contêm credenciais sensíveis. Por padrão, o Kubernetes armazena secrets em etcd sem criptografia. O CIS Benchmark exige que você criptografe secrets em repouso e controle o acesso a eles via RBAC.

Habilite criptografia de secrets no kube-apiserver:

kube-apiserver \
  --encryption-provider-config=/etc/kubernetes/encryption-config.yaml

Arquivo de configuração de criptografia:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: AQUI_COLOQUE_UMA_CHAVE_BASE64_DE_32_BYTES
  - identity: {}

E restrinja acesso via RBAC:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]
  resourceNames: ["app-credentials"]  # Apenas secret específico
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-secrets
  namespace: production
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: secret-reader
subjects:
- kind: ServiceAccount
  name: app-sa

Scanning de Imagens e Vulnerabilidades

O CIS Benchmark recomenda que você escaneie imagens de container antes de implantá-las. Use ferramentas como Trivy ou Grype para detectar vulnerabilidades conhecidas.

Integre o scanning em seu pipeline:

# Instalar Trivy
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

# Escanear imagem
trivy image --severity HIGH,CRITICAL myapp:1.0

# Saída esperada
2024-01-15T10:20:34.123Z    INFO    Vulnerability scanning...
myapp:1.0 (alpine 3.18)

HIGH: CVE-2023-1234 OpenSSL vulnerability
CRITICAL: CVE-2023-5678 Memory leak in libc

Em CI/CD, falhe o build se vulnerabilidades críticas forem encontradas:

# Exemplo com GitHub Actions
- name: Scan with Trivy
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: myapp:${{ github.sha }}
    format: 'sarif'
    output: 'trivy-results.sarif'
    severity: 'CRITICAL,HIGH'

Conclusão

O CIS Benchmark para Kubernetes não é um produto que você compra e instala. É um framework de diretrizes que exige comprometimento com segurança desde o design do cluster. Os três pontos críticos que você deve lembrar são: (1) RBAC granular é a base—nunca confie em permissões padrão; (2) auditoria contínua revela o que você não vê—implemente logging e monitore padrões anormais; (3) segurança é iterativa—use ferramentas como kube-bench regularmente para validar compliance e feche falhas conforme as encontrar. Kubernetes é complexo, mas seguindo essas recomendações você reduz drasticamente a superfície de ataque.

Referências

• CIS Kubernetes Benchmark Official
• Kubernetes Security Documentation
• kube-bench GitHub Repository
• Pod Security Standards
• Kubernetes RBAC Best Practices