Cookbook para Avaliação de Segurança em Containers

Introdução: Em um mundo onde aplicações são empacotadas e orquestradas em escala, containers se tornaram um vetor crítico de risco e, ao mesmo tempo, uma superfície de defesa poderosa quando bem gerida. Este artigo entrega um compêndio técnico para profissionais de segurança que precisam avaliar, validar e melhorar a postura de containers em ambientes cloud-native e on-premises. Vamos cobrir a importância de negócio, riscos operacionais, métodos de avaliação, ferramentas práticas (com comandos para Kali Linux/Parrot OS), playbooks para Blue Teams e Red Teams, métricas acionáveis, estudos de caso reais, além de um checklist operacional para auditoria e resposta. Ao final você terá um “cookbook” aplicável em pentests autorizados, avaliações de segurança e programas de melhoria contínua de hardening.

Contexto Atual e Relevância Estratégica

O ecossistema de containers e orquestração evoluiu de um experimento dev-centric para a espinha dorsal das plataformas de produção em grandes empresas. Kubernetes, Docker e runtimes alternativos (containerd, CRI-O) dominam stacks de entrega contínua e impulsionam microserviços que, se comprometidos, podem expor dados sensíveis, interromper operações e possibilitar movimentos laterais rápidos.

Negócios modernos dependem de velocidade e resiliência. Containers entregam isso, mas também reduzem o tempo entre descoberta e exploração para atacantes. A superfície de ataque é ampla: imagens infectadas, registries públicos privados mal configurados, secrets em variáveis de ambiente, privilégios excessivos no runtime, namespaces mal isolados, e falhas em processos de CI/CD. Além disso, a integração com provedores cloud e serviços de terceiros amplia o blast radius.

Risco de negócio: Um incidente em ambiente containerizado pode resultar em perda de receita (downtime de serviços críticos), impacto em reputação, multas regulatórias (ex: proteção de dados) e custos de remediação que superam investimentos prévios em segurança. Investir em avaliações periódicas reduz riscos e aumenta a maturidade do DevSecOps.

Nos últimos anos houve incidentes que tornam a avaliação de segurança em containers uma prioridade estratégica. Ataques que exploraram imagens maliciosas em registries ou falhas em runtimes provaram que controles tradicionais (firewalls, WAFs) não cobrem o modelo de ameaça – é preciso visibilidade da cadeia de entrega e defesa no runtime.

Por que agora? Três motivos convergem para priorizar avaliações de segurança em containers hoje:

• Escala e velocidade: pipelines CI/CD promovem centenas de builds diários, ampliando a probabilidade de configuração insegura ou inclusão de dependências vulneráveis.
• Complexidade de pilha: containers, service mesh, sidecars e infra ephemeral complicam deteção e resposta tradicionais.
• Regulação e auditoria: frameworks como ISO-27001, NIST-CSF e de setor (financeiro, saúde) exigem controles sobre software supply chain e runtime.

Tendências projetadas para 2025/2026: espera-se maior foco em hardening de supply chains, assinatura obrigatória de imagens nos pipelines, avanço de tecnologias de isolamento (gVisor, Kata Containers), e integração de EDR/EDR-like para ambientes containerizados. Essas tendências aumentam a importância de avaliações regulares que testem não só configurações, mas também a integração entre CI/CD, registries e orchestradores.

Este capítulo contextualiza por que um “cookbook” prático é essencial: avaliações em containers não são apenas about scanner results – envolvem arquitetura, processos, validação humana e métricas que permitam decisões de risco. Nos próximos blocos vamos dissecar fundamentos técnicos e rotas de ataque/defesa em detalhes operacionais.

Fundamentos Técnicos do Tema

Para avaliar segurança de containers com profundidade é preciso dominar conceitos básicos e avançados do stack: imagens, registries, runtimes, namespaces, cgroups, seccomp, capabilities, e o papel do orchestrador (principalmente Kubernetes). Esse capítulo apresenta esses fundamentos com foco no que impacta avaliação prática.

Imagens e registries: Imagens container são camadas imutáveis que combinam sistema de arquivos, binários e metadados. Vulnerabilidades em pacotes dentro da imagem ou na configuração (ex: aplicações rodando como root) são vetores comuns. Registries podem ser públicos (Docker Hub, Quay) ou privados. Configurações incorretas em registries podem expor imagens sensíveis ou permitir push não autorizado.

Runtime e isolamentos: O runtime (containerd, CRI-O, Docker Engine) cria namespaces (PID, NET, MNT, IPC, UTS) e cgroups para isolamento. No entanto, isolamento não é completa: privilégios como CAP_SYS_ADMIN ou montagem indevida de /var/run/docker.sock permitem breakout. Técnicas de hardening incluem drop de capabilities, uso de seccomp profiles e readonly root filesystem.

Orquestrador – Kubernetes: Kubernetes adiciona camadas de complexidade: control plane, kubelet, API server, etcd, CNI, CRI. Configurações inseguros em RBAC, admission controllers ou network policies frequentemente causam explorações. Políticas de segurança (PSP legacy, agora substituídas por alternatives como OPA Gatekeeper, Kyverno e Pod Security Admission) são centrais para impor constraints em runtime.

Networking e Service Mesh: CNI plugins (Calico, Flannel, Cilium) e service meshes (Istio, Linkerd) influenciam a superfície de ataque. Network policies mal definidas podem permitir tráfego lateral; service meshes, sendo complexos, podem introduzir configuração insegura ou expondo mTLS mal gerido.

Supply Chain: O fluxo desde o código-fonte à imagem em produção envolve VCS, pipelines CI/CD, scanners de vulnerabilidade, signing e registries. Contaminação nesta cadeia (ex.: dependências maliciosas, token leakage, pipeline runners com credenciais) é causa frequente de compromissos em produção. Ferramentas como SLSA e in-toto ajudam na integridade da cadeia.

Speciais de kernel e escapes: Muitas explorações de container são baseadas em CVEs no kernel ou má configuração de namespaces. Por isso, é crítica a inspeção de CVEs conhecidos (p.ex. CVE-2021-3156 não é container-specific, mas práticas similares mostram a natureza cross-cutting dos riscos) e avaliação de mitigations como user namespaces.

Detecção e Telemetria: Observabilidade em containers precisa ser granular: logs de audit do kubernetes, events, container stdout/stderr, metrics (Prometheus), traces (OpenTelemetry) e runtime syscall monitoring (Falco, eBPF-based tools). Serviços de logging centralizado e correlação de eventos no SIEM/SOC garantem que anomalias sejam detectadas em tempo aceitável.

Modelos de ameaça: Um bom assessment começa por definição de hipóteses de ataque: imagem maliciosa, credential theft, lateral movement via kubelet, cluster admin compromise. Use MITRE ATT&CK for Containers/Cloud Native quando disponível para mapear técnicas e mitigations.

Conclusão do capítulo: Sem este fundamento, análises superficiais (apenas rodar scanners) perderão o contexto. Avaliações efetivas integram compreensão de arquitetura, princípios de isolamento, e supply chain, e traduzem achados técnicos em risco de negócio para priorização.

Arquitetura, Fluxos e Superfície de Ataque

Avaliar segurança requer mapear a arquitetura completa: desde desenvolvedores que committam código até containers em execução. Vamos decompor essa arquitetura em fluxos de dados, controle e autenticação, identificando pontos de falha e vetores exploráveis.

Fluxo de Build e Deploy: O pipeline CI/CD é o primeiro ponto a mapear. Fluxos típicos: commit em VCS -> pipeline runner (GitLab CI, GitHub Actions, Jenkins) -> build de imagem -> push para registry -> deploy (kubectl, ArgoCD, Flux). Cada etapa requer credenciais, agentes de execução e armazenamento. Avaliação deve enumerar secrets, runners com privilégios elevados e políticas de promoção de imagens.

Fluxo de Runtime: No runtime, o fluxo passa por scheduler, kubelet, runtime e rede CNI. Dados sensíveis trafegam entre serviços, logs são coletados, e operações de manutenção acessam sistemas via bastion ou SRE consoles. Mapear quem/qualou serviço pode executar exec/attach, criar port-forward ou alterar resource manifests ajuda a entender o vector de ataque.

Superfície de ataque típica:

• Imagens: bibliotecas vulneráveis, binários com SUID, backdoors em imagens base
• Registry: fires exposed, permissões de push públicas, tokens vazados
• CI/CD Runners: execução de jobs com privilégios de sistema, runners hospedados com permissões de produção
• Kubernetes API: permissões RBAC exageradas, endpoints expostos, exploits API server
• Nodes: SSH aberto, docker.sock montado, kernel vulnerável permitindo breakout
• Network: policies permissivas, falta de segmentação network, portas expostas
• Secrets: armazenados em plaintext, montados em environment variables
• Sidecars e serviços terceiros: service mesh misconfigurations, insecure sidecar images

Mapa de ataque com exemplos práticos: Um adversário típico pode usar um vetor inicial relativamente trivial, como uma imagem com credenciais hard-coded ou uma vulnerabilidade RCE em um serviço exposto, e então pivotar para comprometer o orchestrador (ex.: explorar uma falha no kubelet) para obter privilégios. Uma vez com privilégios de cluster-admin, o atacante pode criar DaemonSets maliciosos, persistir com cronjobs e instalar backdoors.

Casos de Exploração Específica: Em 2021-2023 vimos casos de registries mal configurados e imagens com miners ou shells web. Em avaliações recentes, adversários usaram montagem de docker.sock em pods para ganhar acesso ao daemon e, via Docker API, spawnar containers com privilégios de host. Na prática, verificar mounts de /var/run/docker.sock e privilégios CAP_SYS_ADMIN deve ser prioridade.

Matriz de risco por camada: Avalie cada camada (build, registry, control plane, node, pod, network) e atribua classificadores: probabilidade, impacto, detectabilidade. Isso orienta a priorização de remediação. Ferramentas como Risk Matrices baseadas em CVSS podem ser úteis, mas devem se adaptar ao contexto operacional (ex.: uma vulnerabilidade de baixo CVSS em um componente crítico pode ter impacto alto).

Exemplos de controles por camada:

• Build: signing de artefatos, scans SCA e SAST, policies de base image trusted.
• Registry: autenticação forte, image immutability, VLANs privadas para registries críticos.
• Control Plane: hardening do API server, RBAC granular, audit logging, encryption at rest (etcd).
• Nodes: kernel atualizado, readonly rootfs, runtime profiles (seccomp), kernel lockdown.
• Pods: PodSecurityAdmission, PSP equivalents, resource quotas e Liveness/Readiness probes seguras.
• Network: network policies, service meshes com mTLS, egress filtering.

Conselho prático: Desenvolva um Threat Model para cada cluster/namespace aplicando STRIDE adaptado a cloud-native. Documente fluxos de dados e identifique pontos com maior exposição de credenciais. Em avaliações, demonstre impacto com provas de conceito (PoC) controladas e documentadas, seguindo regras de escopo e ética.

Cenários Reais e Estudos de Caso

Estudos de caso ajudam a transformar teoria em prática. Aqui relato incidentes documentados e resultados de avaliações que moldaram recomendações modernas de segurança para containers, com foco em lições aplicáveis.

Estudo 1 – Incidente de registry público (Exemplo análogo a casos públicos): Em 2022, múltiplas organizações relataram imagens públicas contendo credenciais e backdoors devido a processos automatizados de CI que pusharam imagens para registries públicos por engano. A descoberta ocorreu via threat hunting e assinaturas em EDR. A lição foi clara: automação sem gates de governance pode vazar artefatos sensíveis. Controles aplicados: policies de push com verificações de assinatura, validações SCA no pipeline e implementação de retenção/scan automático em registries.

Estudo 2 – Kubelet e docker.sock mount abuse: Em auditorias de 2023-2024 em setores financeiro, testes de pentest mostraram que desenvolvedores com permissões reduzidas conseguiam executar pods que montavam /var/run/docker.sock, criando containers com privilégios de host. O ataque permitiu leitura de secrets e eventual exec em nodes. Correções: policies de admission que negavam mounts sensíveis, RBAC revisto e scanners de configuração automatizados (kube-hunter, kube-bench e admission controllers).

Estudo 3 – Supply chain compromise em dependência de linguagem: Exemplo: um pacote npm malicioso transitive entrou em imagens base de serviços microservices. Em alguns clientes, scanners SCA detectaram comportamento anômalo em runtime (exfil via HTTP). Remediações envolveram lockfiles estritos, uso de SBOMs, e adoção de instrumentos de verificação de integridade em build.

Estudo 4 – Exploração de CVE em runtime: Em 2021-2023 houve CVEs que permitiam breakout do container via syscall. Auditorias proativas priorizaram atualizações de kernel e mitigations via sysctl. Em avaliações mais recentes, ataques baseados em eBPF foram simulados, mostrando que ferramentas de runtime detection precisam compreender eBPF para diferenciar comportamento legítimo de abuso.

Boas práticas para PoC em avaliações: Em todos os casos acima, pentesters e avaliadores foram instruídos a fornecer PoCs com escopo claro, evitando persistência não autorizada e preservando integridade do ambiente. Logs e evidências foram capturadas com hashes, timestamps e screenshots, garantindo rastreabilidade para correção.

Comparativo antes/depois de remediação: Em clientes auditados, após aplicar controles recomendados (admission policies, read-only roots, RBAC least-privilege), o tempo médio para escalonamento de privilégio em testes controlados aumentou de minutos para dias, demonstrando ganho de defesa em profundidade.

Lições gerais: (1) Segurança em containers é holística; (2) Automação sem guarda-chuva de segurança é perigosa; (3) Visibility e telemetria são essenciais para detectar comportamento anômalo; (4) Educação de desenvolvedores e SREs sobre riscos reduz erros humanos.

Implementação Prática Step-by-Step

Este capítulo é o coração do cookbook: passos operacionais, comandos para Kali Linux e Parrot OS, validação e rollback. Tudo pensado para avaliações e pentests autorizados. Antes de executar qualquer teste, obtenha autorização por escrito, defina escopo e janelas de teste, e comunique times afetados.

Pré-requisitos: máquina de testes Kali Linux ou Parrot OS com conexões de rede ao ambiente alvo (ou ambiente de laboratório). Permissões e acordos legais assinados. Ferramentas recomendadas: docker/podman, kubectl, trivy, kube-bench, kube-hunter, kubectl-trace (quando aplicável), Falco, sysdig, nmap e ferramentas de exploração quando autorizadas.

Instalação rápida de ferramentas em Kali/Parrot (exemplos):

Passo a passo operacional (cenário prático):

1. Reconhecimento Seguro: Use nmap e kubernetes-aware scanners para mapear superfícies expostas.
   
   # Descoberta de hosts e portas web/API sudo nmap -sS -Pn -p 22,2375,2376,6443,10250,10255,10256 10.0.0.0/24 # Teste de endpoints de Kubernetes API (se autorizado) curl -k https://<k8s-api-server>:6443/ -I

   1 2 3 4 5

   # Descoberta de hosts e portas web/API sudo nmap -sS -Pn -p 22,2375,2376,6443,10250,10255,10256 10.0.0.0/24 # Teste de endpoints de Kubernetes API (se autorizado) curl -k https://<k8s-api-server>:6443/ -I

   
   Validação: obtenha retorno 200/401 para API server; documente headers e versões. Rollback: não aplicável (leitura apenas).
2. Scan de Imagem com Trivy: Identifique CVEs e problemas de config.
   
   # Scaneando imagem local ou remota trivy image --severity CRITICAL,HIGH --format table --input <image-name>:<tag> # Exemplo trivy image --severity CRITICAL,HIGH docker.io/library/nginx:1.23

   1 2 3 4 5

   # Scaneando imagem local ou remota trivy image --severity CRITICAL,HIGH --format table --input <image-name>:<tag> # Exemplo trivy image --severity CRITICAL,HIGH docker.io/library/nginx:1.23

   
   Validação: analise output para CVE IDs, bibliotecas afetadas e versionamento. Rollback: not applicable; se imagem for interna, force rebuild com base image atualizada.
3. Auditoria de Configuração Kubernetes: Use kube-bench e kube-hunter.
   
   # Rodar kube-bench sudo kube-bench node --version <kubernetes-version> # Rodar kube-hunter (modo remoto) sudo kube-hunter --remote <k8s-api-server>

   1 2 3 4 5

   # Rodar kube-bench sudo kube-bench node --version <kubernetes-version> # Rodar kube-hunter (modo remoto) sudo kube-hunter --remote <k8s-api-server>

   
   Validação: registre falhas de benchmark e findings de hunt com evidências. Rollback: aplique correções em ordem de severidade testada em staging primeiro.
4. Detectar mounts sensíveis em pods: Enumerar pods e verificar se /var/run/docker.sock está montado.
   
   kubectl get pods --all-namespaces -o json | jq '.items[] | {ns: .metadata.namespace, name: .metadata.name, volumes: .spec.volumes}' # Filtrar para docker.sock mount kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{"\n"}{range .spec.containers[*].volumeMounts}{.mountPath}{"\n"}{end}{end}' | grep '/var/run/docker.sock'

   1 2 3 4

   kubectl get pods --all-namespaces -o json | jq '.items[] | {ns: .metadata.namespace, name: .metadata.name, volumes: .spec.volumes}' # Filtrar para docker.sock mount kubectl get pods --all-namespaces -o jsonpath='{range .items[*]}{.metadata.namespace}{" "}{.metadata.name}{"\n"}{range .spec.containers[*].volumeMounts}{.mountPath}{"\n"}{end}{end}' | grep '/var/run/docker.sock'

   
   Validação: se encontrado, documente e priorize correção. Rollback: remover mount via atualização do manifest e reapply com kubectl apply -f manifest.yaml
5. Exploração Controlada – Execução em Pod (apenas se autorizado): Teste de breakout via docker.sock.
   
   # Criar um pod que monta docker.sock (apenas em lab autorizado) cat <<EOF > exploit-pod.yaml apiVersion: v1 kind: Pod metadata: name: exploit spec: containers: - name: exploit image: docker:19.03 command: ['sleep', '3600'] volumeMounts: - mountPath: /var/run/docker.sock name: dockersock volumes: - name: dockersock hostPath: path: /var/run/docker.sock EOF kubectl apply -f exploit-pod.yaml kubectl exec -it exploit -- sh -c "docker ps"

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

   # Criar um pod que monta docker.sock (apenas em lab autorizado) cat <<EOF > exploit-pod.yaml apiVersion: v1 kind: Pod metadata:   name: exploit spec:   containers:   - name: exploit     image: docker:19.03     command: ['sleep', '3600']     volumeMounts:     - mountPath: /var/run/docker.sock       name: dockersock   volumes:   - name: dockersock     hostPath:       path: /var/run/docker.sock EOF kubectl apply -f exploit-pod.yaml kubectl exec -it exploit -- sh -c "docker ps"

   
   Validação: se docker ps retornar containers host, prova que existe escalation vector. Rollback: delete pod e reconfigurar admission controller para negar hostPath mounts.
6. Teste de Network Policies: Verificar se namespaces possuem políticas restritivas.
   
   # Listar network policies kubectl get networkpolicies --all-namespaces # Testar comunicação entre pods (usar ferramentas netcat ou busybox) kubectl run -it --rm --restart=Never test-client --image=appropriate/nc -- /bin/sh

   1 2 3 4 5

   # Listar network policies kubectl get networkpolicies --all-namespaces # Testar comunicação entre pods (usar ferramentas netcat ou busybox) kubectl run -it --rm --restart=Never test-client --image=appropriate/nc -- /bin/sh

   
   Validação: tente conexões para portas internas e monitore logs de network policy controller. Rollback: rever policies e aplicar ajustes incrementais.
7. Runtime Detection: Use Falco ou eBPF-based tools para monitorar syscalls suspeitos.
   
   # Ver logs falco (assumindo falco instalado) sudo journalctl -u falco -f # Ou rodar falco em modo local sudo falco -o json_output=true

   1 2 3 4 5

   # Ver logs falco (assumindo falco instalado) sudo journalctl -u falco -f # Ou rodar falco em modo local sudo falco -o json_output=true

   
   Validação: detectar execs inesperados, shells interativos ou escrita em /etc/hosts. Rollback: atualizar ruleset e ajustar policies para reduzir falsos positivos.

Validação e Evidência: Em cada etapa capture timestamps, outputs, hashes (sha256) de arquivos relevantes, screenshots e um resumo curto do impacto. Use SSO e logs de auditoria para correlacionar atividade do tester com ações registradas. Mantenha uma trilha de auditoria para suporte legal e remediação.

Limitações e Riscos: Alguns testes (ex.: manipular etcd via API) podem causar downtime. Faça testes que modifiquem estado apenas em ambientes de teste ou windows autorizados. Documente possíveis efeitos colaterais e planos de rollback antes de iniciar.

Hardening, Controles e Melhores Práticas

Hardening em ambiente containerizado envolve medidas preventivas ao longo da cadeia: imagem, pipeline, registry, runtime e orchestrator. Aqui apresento controles técnicos e operacionais priorizados, com recomendações práticas e snippets de configuração.

1. Imagens confiáveis e SBOM: Use imagens oficiais e restrinja base images aprovadas. Gere e verifique SBOMs (Software Bill of Materials) com ferramentas como syft ou trivy sbom. Integre políticas que neguem deploy de imagens sem SBOM assinado no registro.

Exemplo de política de CI para fail fast: adicionar stage de SCA + assinatura:

2. Registry hardening: Force authentication, enable image immutability for production tags, enable image scanning on push, and limitar acesso via network ACLs. Habilite content trust (cosign) e verificação de assinatura no admission controller.

3. Least privilege e RBAC granular: Reviews periódicos de roles e bindings, uso de Namespaces para separação, e controles de admission que negam criação de clusterroles desnecessárias. Automatize revisão com ferramentas como rakkess e kube-score.

4. Pod Security e Runtime Constraints: Use Pod Security Standards (PSA) ou Gatekeeper/OPA para aplicar policies: runAsNonRoot, readOnlyRootFilesystem, dropCapabilities, seccompProfile, allowPrivilegeEscalation: false, restrict hostPath, restrict hostNetwork/hostPID/hostIPC.

Exemplo de manifest policy (Kyverno/OPA pseudo):

5. Network Policies e Service Mesh: Implementar network policies por default deny e aplicar regras explícitas de comunicação. Para ambientes com service mesh, habilitar mTLS e políticas de autorização no mesh para segregar tráfego.

6. Runtime monitoring e EDR: Ferramentas como Falco (syscall monitoring), eBPF-based detectors e runtime scanners (Sysdig Secure, Anchor, Aqua) ajudam a detectar comportamentos anômalos. Integre alertas em SIEM/SOC com playbooks para resposta.

7. Patch Management e Imutabilidade: Evitar mutações manuais em nodes; prefira imutabilidade: redeploy em vez de patch in-situ quando possível. Mantenha imagens base atualizadas e automatize builds regulares com rebuilds de base images.

8. Secrets Management: Nunca colocar secrets em imagens; use soluções de secret management (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) e montar secrets via CSI drivers com rotacionamento e acesso controlado.

9. Auditing e Logging: Habilitar audit logs do Kubernetes, centralizar logs, aplicar retenção adequada, e garantir que logs de control plane (apiserver, etcd) estejam protegidos e com integridade.

10. Policy as Code e CI/CD gating: Qualquer alteração em infra deve passar por policy checks, assinaturas e revisão. Implementar gating que valida RBAC, network policies, e presença de securityContext antes do deploy.

Checklist de Prioridades: (1) negar hostPath e docker.sock; (2) aplicar PSA/OPA; (3) escanear imagens em pipeline; (4) controlar registries; (5) habilitar logging e alerting; (6) testar processos de resposta.

Playbooks Operacionais para Blue Team e Red Team

Playbooks traduzem procedimentos em passos repetíveis. Aqui apresento playbooks separados para Blue Team (detecção, contenção, remediação) e Red Team (avaliação, exploração controlada, reporting). Ambos respeitam regras de ética e escopo.

Playbook Blue Team – Detecção e Contenção:

• Objetivo: Detectar atividade maliciosa em containers, conter impacto e coletar evidência.
• Pré-condições: Logs centralizados, Falco ou similar rodando, RBAC e audit logging ativo.
• Passos:
  • 1) Detectar anomalia: alerta Falco para exec em container com shell interativo ou escrita em /etc/passwd.
  • 2) Enriquecer contexto: correlacione com logs de API server, events, e registros de CI/CD para entender origem do deploy.
  • 3) Isolar workload: aplicar NetworkPolicy deny-all para namespace afetado e scale-to-zero do deployment suspeito; alternativamente, cordon e drain do node se nécessaire.
  • 4) Forense ao vivo: snapshot do filesystem do container e coleta de processos (ps aux), conexões de rede (ss/netstat) e outputs de lsof. Utilize ferramentas compatíveis com containers (nsenter, cri-tools).
  • 5) Reforçar controles: aplicar OPA/Gatekeeper policy para negar a mesma configuração que permitiu o ataque; rotacionar secrets possivelmente expostos.
  • 6) Remediação: remover artefatos maliciosos, reconstruir imagens a partir de código-fonte conhecido, e redeploy de imagens verificadas e assinadas.
  • 7) Post-mortem e medidas preventivas: documentar root cause, atualizar playbooks e treinar times envolvidos.
• Evidência a coletar: hashes de binários, log extracts, snapshots de memória (quando possível), imagens suspeitas do registry, e timeline completa.

Playbook Red Team – Avaliação e Exploração Autorizada:

• Objetivo: Simular adversário para avaliar deteção e resposta, respeitando regras e não causando dano além do escopo.
• Pré-condições: Escopo por escrito, janelas aprovadas, pontos de contato de emergência.
• Passos:
  • 1) Reconhecimento passivo: coletar manifest públicos, endpoints expostos e informações sobre registries.
  • 2) Exploração inicial: deploy de pod bem comportado que tenta detectar mounts sensíveis e permissões; documentar findings sem manipular state crítico.
  • 3) Escalada controlada: ao encontrar mount docker.sock, simular exfil tentando somente listar containers e recuperar image manifests; evitar spawn de containers que afetem produção. Capture outputs como prova.
  • 4) Movimentação lateral em cluster: testar acesso a api-server via service accounts encontradas; tente listar secrets com RBAC permissivo, documente e capture evidências.
  • 5) Persistência simulada: em vez de instalar backdoors, demonstrar capacidade com pod ephemeral e mostrar comando que permitiria persistência (ex.: criar DaemonSet) sem executar.
  • 6) Reporting técnico: evidências com timestamps, PoC controlados, impacto estimado, recomendações priorizadas.
• Regras de ouro: não alterar dados de produção, evitar movimentação que cause downtime, e coordenar rollback junto ao time operacional.

Playbook comum sobre comunicação: sempre notificar pontos de contato quando houver indicadores de risco crítico (ex.: E2E compromise) e fornecer canais seguros (PGP, SSO logs) para troca de evidência sensível.

Métricas, KPIs e Auditoria Técnica

Métricas transformam segurança em linguagem de negócio. Para programas de avaliação de containers é vital monitorar KPIs que reflitam maturidade e risco residual. Aqui proponho métricas técnicas e formas de auditoria que sustentam decisões.

Métricas operacionais recomendadas:

• Tempo Médio de Detecção (MTTD) para eventos container-related (ex.: execs inesperados, imagem não assinada): meta < 15 minutos em ambientes críticos.
• Tempo Médio de Resposta (MTTR) para incidents envolvendo containers: target dependente do SLA, tipicamente < 4 horas para contenção inicial.
• Percentual de imagens em produção com vulnerabilidades críticas/HIGH sem correção: objetivo < 5%.
• Porcentagem de deploys com SBOM e assinatura verificada: meta 100% para produção.
• Percentual de pods rodando com securityContext mínimo (runAsNonRoot, readonlyRootFilesystem): objetivo > 95%.
• Compliance com CIS Benchmarks (Kubernetes/Docker): pontuação média e evolução por release.

Métricas de maturidade: Nível de integração de security checks no pipeline (nenhum, parcial, completo), utilização de Policy-as-Code, e cobertura de observabilidade (percentual de namespaces com Falco/EDR instrumentados).

Auditoria Técnica: Combine verificações automatizadas (kube-bench, trivy, snyk) com revisão manual: RBAC review, network policy review, e verificação de secrets. Auditorias periódicas trimestrais são recomendadas para ambientes dinâmicos; auditorias de alto risco devem ser mensais.

Exemplo de relatório técnico: cada vulnerabilidade deve conter: CVE, descritor técnico, localização (imagem, node, pod), evidência (logs, output do scanner), risco comercial (alto/médio/baixo), recomendação, e owner responsável. Triage automática baseada em risco e exposure facilita priorização.

KPIs de investimento: retorno do investimento pode ser medido como redução do MTTD/MTTR, diminuição do número de incidentes por trimestre, e redução de vulnerabilidades críticas em produção – métricas que correlacionam segurança com continuidade de negócios.

Erros Comuns, Armadilhas e Correções

Muitos problemas recorrentes aparecem em avaliações. Aqui destaco erros típicos, como detectá-los e passos de correção concretos com exemplos técnicos.

Erro 1 – Permissões excessivas em ServiceAccounts: Sintoma: ServiceAccount com cluster-admin binding. Detecção: kubectl get clusterrolebindings -o json | jq. Correção: aplicar principle of least privilege, criar roles específicas por namespace e usar Workload Identity quando disponível.

Erro 2 – Montagem de hostPath/dockersock em pods: Sintoma: pods que listam /var/run/docker.sock mount. Detecção: audit pods. Correção: Admission controller rejecting hostPath mounts and use CSI drivers for necessary mounts.

Erro 3 – Depósito de secrets em image ou env vars: Sintoma: presence of keys in image layers or kubectl describe pod shows env var secrets. Detecção: scan image layers (dive, trivy fs). Correção: migrate to Vault and use secret stores via CSI drivers; rotate keys compromised.

Erro 4 – Falta de RBAC auditing: Sintoma: logs insuficientes, role changes não auditadas. Correção: habilitar audit policy do api-server e garantir logs forward para SIEM com integridade e retenção adequada.

Erro 5 – Ausência de escaneamento de imagens no pipeline: Sintoma: imagens em produção com vulnerabilidades. Correção: integrar SCA e SAST no CI, negar deploy sem assinatura e SBOM.

Erro 6 – Over-reliance em network segmentation inexistente: Sintoma: networkPolicy não aplicada, todos os pods podem conversar livremente. Correção: aplicar deny-all padrão e modelar exceptions via service accounts.

Erro 7 – Confusão entre cloud IAM e Kubernetes RBAC: Sintoma: acesso via cloud provider expõe recursos K8s. Correção: mapear bindings e auditar cross-plane roles; separar contas e políticas por função.

Práticas para evitar armadilhas: automatize checks, mantenha comunicação constante entre Devs e SecOps, e promova “shift-left” (segurança no desenvolvimento). Simulações regulares e exercícios de tabletop com SREs reduzem erros operacionais.

FAQ Técnico para Busca Orgânica

Esta seção responde perguntas práticas que profissionais buscam com frequência. Cada resposta é objetiva, pensada para featured snippets e SEO sem parecer spam.

Pergunta 1: O que devo escanear primeiro em um ambiente com containers?

Priorize: imagens em uso em produção, políticas de admission, mounts de hostPath e docker.sock, e permissões de ServiceAccounts. Isso oferece maior redução de risco por esforço.

Pergunta 2: Quais ferramentas uso para avaliação inicial em Kali Linux?

Ferramentas essenciais em Kali: trivy (image scanning), kube-bench (CIS checks), kube-hunter (recon), nmap (network discovery), falco (runtime detection), e kubectl para interrogar cluster. Instale via apt/pip conforme necessário.

Pergunta 3: Como detectar se uma imagem contém secrets?

Use scanners que inspecionem camadas de imagem e filesystem: truffleHog, detect-secrets, ou trivy com regras de secretos. Também faça análise manual das camadas com dive e grep em arquivos comuns (.env, config files).

Pergunta 4: O que é Pod Security Admission e por que devo usar?

Pod Security Admission aplica padrões (privileged/restricted) para garantir que pods obedeçam constraints de segurança (runAsNonRoot, capabilities). É uma defesa primária contra configurações inseguras.

Pergunta 5: Como protegemos o registry?

Habilite autenticação, TLS, assinatura de imagens (cosign), scans automáticos, network ACLs e policies de retenção. Isolar registry em rede privada e limitar push a roles específicos reduz risco.

Pergunta 6: O que fazer se detectar docker.sock montado em um pod?

Contenção imediata: isolar namespace, remover o pod e aplicar admission policy que negue hostPath mounts. Em paralelo, auditar histórico para identificar quem/qual pipeline criou o pod e rotacionar credenciais comprometidas.

Pergunta 7: Qual a diferença entre runtime security e image scanning?

Image scanning detecta vulnerabilidades em artefatos estáticos. Runtime security monitora comportamento em execução (syscalls, processos, conexões). Ambos são complementares: uma imagem pode passar scan mas comportar-se mal em runtime por configurações ou exploits.

Pergunta 8: Como medir sucesso em um programa de segurança para containers?

Por métricas como redução de vulnerabilidades críticas em produção, MTTD/MTTR melhores, percentual de deploys com SBOM/assinatura e aumento de cobertura de regras de policy.

Pergunta 9: Que CVEs devo priorizar?

Priorize CVEs que permitam privilégio escalation, RCE, ou fuga de container (breakout) em runtimes/kernel. Use CVSS + contexto operacional (exposição, criticidade do serviço) para priorização.

Pergunta 10: Ferramentas gratuitas para começar?

Trivy, kube-bench, kube-hunter, Falco, Clair (open source), Anchore Engine, e ferramentas de SCA como Snyk (tem versões gratuitas) são bons pontos de partida.

Pergunta 11: Como documentar evidências em uma avaliação?

Capture outputs cronometrados, hash de arquivos, screenshots, e scripts usados. Inclua descrições do impacto e passos de reprodução concisos. Preserve logs do cluster e snapshots quando possível.

Pergunta 12: Qual a política de testes para ambientes sensíveis?

Evite testes que alterem estado crítico, priorize staging, defina janelas curtas e rolbacks claros, e garanta backup antes de executar mudanças que podem causar downtime.

Considerações Finais

Avaliações de segurança em containers são complexas, multidisciplinares e essenciais para proteger infraestruturas modernas. Este cookbook mostrou caminhos técnicos e operacionais para mapear superfícies, executar testes controlados em Kali/Parrot, implantar detecções efetivas e estabelecer métricas que transformam segurança em ação comercial. A mensagem central é a mesma: ferramentas sozinhas não bastam. Defesas reais nascem da integração entre pipeline, arquitetura, observabilidade e processos humanos bem treinados.

Você agora tem um roteiro para avaliar ambientes, demonstrar impacto com provas de conceito seguras, priorizar remediações e construir um ciclo de melhoria contínua. Comece pequeno: identifique os risks mais fáceis de explorar e corrija-os. Em seguida, expanda governance, automação e telemetry. Segurança em containers é uma jornada técnica – e essa jornada vale cada esforço para reduzir o risco de incidentes que podem ser caros e difíceis de remediar.

Recursos Visuais Sugeridos

Materiais públicos com diagramas, arquiteturas e visuais oficiais para apoiar o estudo do tema.

• MITRE ATT&CK – matriz visual de táticas, técnicas e procedimentos.
• CISA Resources – alertas, advisories e diagramas de arquitetura defensiva.
• NIST Cybersecurity Framework – figuras oficiais e referências de controles.
• ENISA – relatórios anuais com gráficos e mapas de ameaça.
• Kali Linux – documentação oficial com fluxos práticos.
• Parrot Security – documentação oficial com arquitetura modular.

Referências

Recursos oficiais e técnicos consultados para construir este material e para aprofundamento:

• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf (NIST – Application Container Security Guide)
• https://kubernetes.io/docs/concepts/security/overview/ (Kubernetes Security Overview)
• https://docs.docker.com/engine/security/ (Docker Engine Security)
• https://github.com/aquasecurity/trivy (Trivy – Vulnerability Scanner)
• https://github.com/aquasecurity/kube-bench (kube-bench – CIS Benchmark checks)
• https://falco.org/ (Falco – Runtime Security)
• https://slsa.dev/ (SLSA – Supply chain security framework)
• https://github.com/ossf/scorecard (OSS-F Scorecard para avaliação de segurança em upstream)
• https://www.cisecurity.org/benchmark/ (CIS Benchmarks para Docker/Kubernetes)
• https://github.com/aquasecurity/kube-hunter (kube-hunter – Kubernetes exploration)
• https://in-toto.io/ (in-toto – framework de integridade de supply chain)
• https://github.com/sigstore/cosign (cosign – Signing container images)
• https://docs.anchore.com/ (Anchore – Image scanning)
• https://www.cloudsecurityalliance.org/ (CSA – Cloud Native Security resources)
• https://attack.mitre.org/matrices/enterprise/ (MITRE ATT&CK Matrix)
• https://github.com/ossf/ (Open Source Security Foundation – projetos relacionados)

1. Escopo e autorização: Obtenha documento assinado com limites de IP, namespaces e tempo de execução.
2. Reconhecimento: Em Kali:
   
   sudo nmap -sS -Pn -p 6443,10250,2375 10.10.0.0/24 git clone git@github.com:empresa/repo.git (se autorizado)

   1 2 3

   sudo nmap -sS -Pn -p 6443,10250,2375 10.10.0.0/24 git clone git@github.com:empresa/repo.git (se autorizado)

3. Scan de Imagens: Em Kali:
   
   trivy image --severity CRITICAL,HIGH --format json -o report.json registry.empresa/app:latest jq '.Results[] | {Target: .Target, Vulnerabilities: .Vulnerabilities | length}' report.json

   1 2 3

   trivy image --severity CRITICAL,HIGH --format json -o report.json registry.empresa/app:latest jq '.Results[] | {Target: .Target, Vulnerabilities: .Vulnerabilities | length}' report.json

   
   Validação: abra report.json e confirme CVE IDs. Rollback: solicitar rebuild de imagem com base image atualizada.
4. Auditoria Kubernetes:
   
   kubectl get pods --all-namespaces -o wide kubectl get clusterrolebindings -o json | jq '.items[] | {name: .metadata.name, subjects: .subjects}'

   1 2 3

   kubectl get pods --all-namespaces -o wide kubectl get clusterrolebindings -o json | jq '.items[] | {name: .metadata.name, subjects: .subjects}'

5. Teste controlado de docker.sock (lab/autorizado):
   
   # Criar pod de teste kubectl apply -f exploit-pod.yaml kubectl exec -it exploit -- sh -c "docker ps" # Capturar output e coletar logs kubectl logs exploit > exploit.log sha256sum exploit.log

   1 2 3 4 5 6 7

   # Criar pod de teste kubectl apply -f exploit-pod.yaml kubectl exec -it exploit -- sh -c "docker ps" # Capturar output e coletar logs kubectl logs exploit > exploit.log sha256sum exploit.log

   
   Rollback: kubectl delete -f exploit-pod.yaml; revisar admission policies.
6. Detecção em Runtime:
   
   sudo falco -o json_output=true > falco-output.json & tail -f falco-output.json | jq '.'

   1 2 3

   sudo falco -o json_output=true > falco-output.json & tail -f falco-output.json | jq '.'

   
   Validação: correlacione events Falco com timestamps de deploy.
7. Report e Remediação: Forneça relatório com prioridades, PoC, recomendações e plano de rollback. Acompanhe execução do patch e testes pós-remediação.

Checklist Blue Team:

• Detecção: Falco/EDR instalado em todos nodes; regras para execs em containers; SIEM recebendo audit logs.
• Contenção: Playbook pronto para isolar namespaces e aplicar networkPolicy deny-all.
• Hardening: PodSecurity aplicado; readonly rootfs; drop capabilities; seccomp profile restritivo.
• Logging: Audit logs do API server habilitados e armazenados com integridade.
• Recovery: Processos de rebuild de imagens e re-deploy automatizados; backups e snapshots testados.

Checklist Red Team:

• Escopo Autorizado: Documento assinado com restrições claras.
• Hipóteses: Definição de vetores testados (docker.sock, RBAC, images, network).
• Execução: Scripts e comandos documentados; evitar alterações permanentes em produção.
• Evidência: Logs, outputs, screenshots e hashes coletados e fornecidos de forma segura.
• Reporte: Triage com impacto, recomendações e PoC controlados; comunicar riscos críticos imediatamente.

Recursos Visuais Sugeridos:

• https://kubernetes.io/docs/concepts/architecture/overview/ (Arquitetura Kubernetes)
• https://slsa.dev/spec/v1/ (SLSA model visualization and artifacts)
• https://falco.org/docs/rules/ (Regras Falco examples)
• https://github.com/aquasecurity/trivy#usage (Trivy usage examples)
• https://attack.mitre.org/ (MITRE ATT&CK matrix visual)
• https://github.com/ossf/criticality_score (OSS Fator de criticality – visual)