PARTE C — Labs práticos 🧪

Docker é acessível (instale o Docker Desktop/Engine). K8s use nos labs online, sem precisar montar cluster.

Lab 1 — Rodar e inspecionar um container (🟢)

docker run -d --name lab nginx:alpine
docker inspect lab --format 'user={{.Config.User}}  privileged={{.HostConfig.Privileged}}'
docker exec lab id     # está rodando como root? (muitas imagens rodam!)
docker rm -f lab

Observe: user= vazio = root; id mostra uid 0. Lição: o padrão de muitas imagens é inseguro (A.4).

Lab 2 — Escanear uma imagem por CVEs (🟢)

# instale o Trivy (aquasecurity) e rode:
trivy image nginx:alpine --severity HIGH,CRITICAL | head -30

Observe: vulnerabilidades conhecidas na imagem. Lição: imagem mínima + scan = menos superfície (A.5).

Lab 3 — Auditar os SEUS containers (🟢) — Ex. 42

# containers rodando como root? (deve ser vazio)
docker ps -q | xargs -r docker inspect --format '{{.Name}}: user={{.Config.User}}' | grep 'user=$'
# capabilities perigosas / privilegiado?
docker ps -q | xargs -r docker inspect --format '{{.Name}} priv={{.HostConfig.Privileged}} caps={{.HostConfig.CapAdd}}'

Faça: rode contra o host do seu n8n. Lição: aplique o hardening da tabela A.4 (DOC §4.4).

Lab 4 — Endurecer um docker-compose (🟡 leitura/edição)

Pegue o compose do seu n8n e confirme: user: não-root, cap_drop: [ALL], no-new-privileges, read_only, limites de memória/pids, expose em vez de ports para Redis/Postgres. Lição: é o Ex. 42 na prática.

Lab 5 — Kubernetes seguro (online, opcional)

• Play with Kubernetes (labs no navegador) para o vocabulário.
• Kubernetes Goat (deliberadamente vulnerável) + kube-bench/kube-hunter (auditam contra o CIS Benchmark). Avançado — só se for para K8s.

PARTE D — Autoavaliação ✅

Responda de memória:

1. Qual a diferença de isolamento entre um container e uma VM, e por que importa?
2. Por que não se deve rodar um container como root nem embutir segredo na imagem?
3. Cite três controles de hardening de container.
4. O que é o RBAC do Kubernetes e a que conceito do Módulo 6 ele corresponde?
5. Por que "Secret" do Kubernetes (base64) não é o mesmo que segredo criptografado?
6. O que é container escape e qual a principal defesa?
7. Qual é o padrão de rede entre pods no K8s, e como corrigir?

1. A VM tem kernel próprio (isolamento forte); o container compartilha o kernel do host (isolamento mais fino). Importa porque um container mal configurado pode escapar para o host (A.1).
2. Root no container ≈ risco de root no host se houver escape; e segredo na imagem fica nas camadas, legível por quem puxa a imagem (A.2/A.4).
3. Quaisquer três: usuário não-root, cap_drop: [ALL], no-new-privileges, read_only, limites de recurso, secrets fora da imagem (A.4).
4. É o controle de "quem pode fazer o quê" no cluster — corresponde ao IAM (Módulo 6). Menor privilégio por service account (B.2).
5. Base64 é codificação, não criptografia — qualquer um decodifica. Precisa de encryption at rest + RBAC (B.3).
6. Sair do container para o host. Defesa: Pod Security restricted / container não-privilegiado, não-root, kernel atualizado (A.1/B.5/B.6).
7. Padrão = todos os pods se comunicam (aberto). Corrige-se com NetworkPolicy deny-all + liberar só o necessário (B.4).</details>

Checklist prático:

[ ] Rodei um container e confirmei se ele roda como root (id)
[ ] Escaneei uma imagem com Trivy
[ ] Auditei meus containers (user/privileged/caps) — Ex. 42
[ ] Revisei meu docker-compose contra os controles A.4
[ ] Entendi o vocabulário K8s (pod/service/ingress/namespace)
[ ] Sei por que Secret base64 do K8s não é criptografia
[ ] (opcional) Rodei kube-bench/Kubernetes Goat

Conclusão: 5/7 do quiz + auditoria dos seus containers.