<h2>O que é CIS Benchmark para Kubernetes</h2>
<p>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.</p>
<p>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.</p>
<h2>Pilares Principais do CIS Benchmark para Kubernetes</h2>
<h3>Controle de Acesso e Autenticação (RBAC)</h3>
<p>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.</p>
<p>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:</p>
<pre><code class="language-yaml"># 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</code></pre>
<p>Depois, use esse service account em seu Deployment:</p>
<pre><code class="language-yaml">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"</code></pre>
<p>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 (<code>*</code>) em rules, que devem ser evitadas.</p>
<h3>Políticas de Segurança de Pod (Pod Security Policy / Pod Security Standards)</h3>
<p>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).</p>
<p>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:</p>
<pre><code class="language-yaml"># 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</code></pre>
<p>E uma definição de pod que atende ao padrão Restricted:</p>
<pre><code class="language-yaml">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: {}</code></pre>
<p>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.</p>
<h3>Auditoria e Logging</h3>
<p>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.</p>
<p>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:</p>
<pre><code class="language-yaml">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</code></pre>
<p>Você aplica isso adicionando flags ao kube-apiserver:</p>
<pre><code class="language-bash">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</code></pre>
<p>Depois, integre esses logs em um sistema de monitoramento centralizado (ELK, Splunk, etc.) para detectar padrões anormais automaticamente.</p>
<h2>Verificação Prática: Ferramentas de Auditoria</h2>
<h3>kube-bench: Automatizando Verificações CIS</h3>
<p>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.</p>
<p>Instale e execute em seu cluster:</p>
<pre><code class="language-bash"># 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</code></pre>
<p>O kube-bench percorre todos os controles CIS e retorna algo assim:</p>
<pre><code>[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</code></pre>
<p>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:</p>
<pre><code class="language-yaml"># 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</code></pre>
<h3>Verificação Manual de Controles Críticos</h3>
<p>Algumas verificações você deve fazer manualmente ou via scripts custom. Aqui está um exemplo de script que valida controles essenciais:</p>
<pre><code class="language-bash">#!/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</code></pre>
<h2>Hardening Avançado: Além do Básico</h2>
<h3>Isolamento de Rede com Network Policies</h3>
<p>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.</p>
<p>Uma policy básica que nega todo tráfego por padrão e permite apenas o necessário:</p>
<pre><code class="language-yaml">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</code></pre>
<p>Isso garante que apenas tráfego autorizado flua entre pods. Qualquer requisição não explicitamente permitida é bloqueada.</p>
<h3>Gerenciamento de Secrets</h3>
<p>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.</p>
<p>Habilite criptografia de secrets no kube-apiserver:</p>
<pre><code class="language-bash">kube-apiserver \
--encryption-provider-config=/etc/kubernetes/encryption-config.yaml</code></pre>
<p>Arquivo de configuração de criptografia:</p>
<pre><code class="language-yaml">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: {}</code></pre>
<p>E restrinja acesso via RBAC:</p>
<pre><code class="language-yaml">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</code></pre>
<h3>Scanning de Imagens e Vulnerabilidades</h3>
<p>O CIS Benchmark recomenda que você escaneie imagens de container antes de implantá-las. Use ferramentas como Trivy ou Grype para detectar vulnerabilidades conhecidas.</p>
<p>Integre o scanning em seu pipeline:</p>
<pre><code class="language-bash"># 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</code></pre>
<p>Em CI/CD, falhe o build se vulnerabilidades críticas forem encontradas:</p>
<pre><code class="language-yaml"># 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'</code></pre>
<h2>Conclusão</h2>
<p>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: <strong>(1) RBAC granular é a base</strong>—nunca confie em permissões padrão; <strong>(2) auditoria contínua revela o que você não vê</strong>—implemente logging e monitore padrões anormais; <strong>(3) segurança é iterativa</strong>—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.</p>
<h2>Referências</h2>
<ul>
<li><a href="https://www.cisecurity.org/benchmark/kubernetes" target="_blank" rel="noopener noreferrer">CIS Kubernetes Benchmark Official</a></li>
<li><a href="https://kubernetes.io/docs/concepts/security/" target="_blank" rel="noopener noreferrer">Kubernetes Security Documentation</a></li>
<li><a href="https://github.com/aquasecurity/kube-bench" target="_blank" rel="noopener noreferrer">kube-bench GitHub Repository</a></li>
<li><a href="https://kubernetes.io/docs/concepts/security/pod-security-standards/" target="_blank" rel="noopener noreferrer">Pod Security Standards</a></li>
<li><a href="https://kubernetes.io/docs/reference/access-authn-authz/rbac/" target="_blank" rel="noopener noreferrer">Kubernetes RBAC Best Practices</a></li>
</ul>
<p><!-- FIM --></p>