Emulação em Ambientes Kubernetes

Nota da pasta 04 - Purple Teaming em Cloud e Containers, no Capítulo 19 (Purple Teaming Contínuo).
Trata da emulação de adversário em Kubernetes com técnicas testáveis como exec em pod, pod privilegiado, abuso de service account token e hostPath, telemetria de audit logs e Falco e os guardrails que permitem testar sem quebrar o cluster.
Dialoga com o hunting em containers do Capítulo 08, com o PRT.4 do Capítulo 15 e com o painel de cobertura da pasta 03.

1. Contexto e Posicionamento na Biblioteca

Kubernetes concentra cargas críticas com um modelo de segurança próprio, baseado em RBAC, service accounts, políticas de pod e um plano de controle que registra tudo em audit logs. O adversário que alcança um pod explora essa superfície com técnicas que o EDR clássico quase não vê, e por isso a validação de detecções em Kubernetes exige emulação dedicada, com telemetria nativa do plano de controle e detecção de runtime no plano de dados. Esta nota desenha essa emulação de forma defensiva e controlada, com o foco permanente em testar sem quebrar o cluster.

A nota dialoga com o hunting em containers e Kubernetes do Capítulo 08, que descreve o que caçar na telemetria de runtime, e com o controle PRT.4 do Capítulo 15, que trata do monitoramento de containers como capacidade. Aqui o foco é o lado ofensivo controlado: técnicas testáveis, guardrails de execução, leitura da telemetria e o ciclo de verificação de detecção que alimenta o painel da pasta 03. O regime operacional repete o capítulo: cluster de teste dedicado, namespaces de laboratório, service accounts mínimas e autorização formal.

2. A Superfície de Ataque e os Pré-Requisitos de Telemetria

A superfície de ataque em Kubernetes se divide em duas camadas com telemetrias distintas. No plano de controle, a API server aceita todas as operações, criar pods, ler secrets, listar recursos, e cada chamada é registrada nos audit logs com identidade, verbo, recurso e resposta. No plano de dados, os nós executam os containers, e o comportamento dentro do container, processos, syscalls, arquivos e rede, é o território da detecção de runtime com Ferramentas como Falco, eBPF ou o agente do EDR compatível. A emulação exerce as duas camadas, porque é a correlação entre elas que as detecções maduras exploram.

Os pré-requisitos de telemetria determinam o valor da rodada, e a tabela resume o mínimo indispensável antes de qualquer teste.

A política de audit do API server é o ajuste mais negligenciado e o mais crítico. Uma política que registra apenas metadados esconde justamente o corpo das requisições que caracteriza o abuso, como a especificação de um pod privilegiado, e a emulação fica cega. A configuração de laboratório deve registrar requestObject nas operações de escrita, com cuidado de não capturar secrets em texto claro em produção, e essa tensão entre riqueza de telemetria e exposição de segredos é um dos pontos de atenção da nota.

3. Técnicas Testáveis no Cluster

As técnicas a seguir representam o núcleo do comportamento de adversário em cluster conforme os relatórios públicos e o mapeamento ATT&CK de containers. Cada uma tem teste controlado e telemetria esperada determinística, o que as torna adequadas ao regime contínuo da biblioteca.

Cada teste usa imagens e rótulos exclusivos do laboratório, como o prefixo pt-lab no nome do pod e uma imagem própria marcada, o que permite filtrar a telemetria sem ambiguidade e evita qualquer semelhança com carga de produção. A disciplina de marcação é também a que viabiliza a limpeza automatizada no fim da rodada, apagando tudo que carrega o rótulo do teste.

4. Guardrails: Como Testar sem Quebrar o Cluster

O princípio estrutural é que a emulação roda em cluster dedicado, nunca no cluster de produção, e que mesmo no cluster de teste os testes ficam confinados a um namespace de laboratório com RBAC restritivo. O namespace de lab tem service accounts próprias com papéis mínimos, quotas de recursos para impedir que um teste consuma o nó, e uma NetworkPolicy que isola a rede dos pods de teste. Com esse desenho, um teste mal comportado falha dentro do lab em vez de degradar o cluster inteiro.

Os guardrails específicos das técnicas sensíveis valem itemização, porque são diferentes dos guardrails de endpoint.

• Pod privilegiado e hostPath rodam sempre em nó de teste dedicado, com disk rótulo do lab, e o hostPath aponta para um diretório criado só para o teste, nunca para a raiz do nó com escrita.
• O abuso de service account token usa uma SA de teste criada para a rodada, com papel de leitura restrito, e o token é revogado pela remoção da SA ao fim do teste.
• Nenhum teste altera componentes do plano de controle, como kube-system, e a política de RBAC do lab nega operações fora do namespace de teste.
• Testes de rede usam destinos internos do cluster, e o egresso para internet é bloqueado por NetworkPolicy no namespace do lab.
• A limpeza automatizada apaga por rótulo todos os pods, secrets e rolebindings do teste, e a verificação de limpeza é passo registrado na ficha da rodada.

O bloco a seguir ilustra a definição do namespace de lab com as proteções declaradas, servindo de ponto de partida para o cluster de teste.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pt-lab-quota
  namespace: pt-lab
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: 8Gi
    secrets: "5"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: pt-lab-isolado
  namespace: pt-lab
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
  ingress: []
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
    ports:
    - protocol: UDP
      port: 53

Com quota e política de rede declaradas, o pior cenário de um teste mal comportado é a falha confinada ao namespace, e o pior cenário de rede é a impossibilidade de egresso, que é exatamente o comportamento desejado.

5. Exemplo de Cenário com Verificação de Detecção

O cenário de referência emula a cadeia clássica de comprometimento de cluster: acesso a um pod, extração do token da service account, descoberta via API e tentativa de escape com pod privilegiado. O passo a passo documenta a execução controlada e a evidência esperada.

Cenário PT-K8S-01, cadeia de escape simulada
Objetivo: validar audit logs, regras de runtime e alerta de correlação
Cluster: cluster de teste dedicado, namespace pt-lab, nó de teste isolado
Passos:
  1. executar shell no pod de teste existente com kubectl exec
  2. ler o token da SA montada em /var/run/secrets/.../token
  3. listar pods e secrets do namespace com o token da SA de teste
  4. tentar criar pod privilegiado com hostPath no namespace pt-lab
  5. verificar a criação do pod privilegiado e encerrar imediatamente
Telemetria esperada:
  audit: pods/exec em 1, get token em 2, list em 3, create pod em 4
  runtime: Falco alerta de shell em container e de container privilegiado
  correlação: regra que cruza exec + list em rajada + create privilegiado
Limpeza: apagar por rótulo pt-lab=yes e confirmar ausência de pods residuais

O trecho YAML a seguir mostra o pod privilegiado do passo 4, com as marcações do lab e o hostPath apontando para o diretório de teste, representativo do teste sem risco real de escape porque roda em nó dedicado e é removido imediatamente.

apiVersion: v1
kind: Pod
metadata:
  name: pt-lab-priv-01
  namespace: pt-lab
  labels:
    pt-lab: "yes"
spec:
  serviceAccountName: pt-lab-sa
  nodeSelector:
    lab-role: "teste-isolado"
  restartPolicy: Never
  containers:
  - name: main
    image: registry.lab/pt-lab/busybox:estavel
    command: ["sleep", "120"]
    securityContext:
      privileged: true
    volumeMounts:
    - name: hosttest
      mountPath: /hosttest
  volumes:
  - name: hosttest
    hostPath:
      path: /var/lib/pt-lab
      type: DirectoryOrCreate

A verificação no SIEM cruza as duas camadas de telemetria na janela do teste. A consulta KQL a seguir exemplifica a busca pelos audit logs da cadeia, com o padrão adaptável ao esquema do coletor.

// Cadeia do cenário PT-K8S-01 nos audit logs do cluster de teste
KubeAuditLogs
| where TimeGenerated between (datetime(2025-10-14 10:00) .. datetime(2025-10-14 10:30))
| where Namespace == "pt-lab"
| project TimeGenerated, User, Verb, Resource, Namespace, Name, ResponseCode
| where Verb in ("create", "get", "list") and Resource in ("pods", "secrets", "pods/exec")
| order by TimeGenerated asc

A ficha de resultado avalia cada camada separadamente. Se o Falco alertou o container privilegiado e o audit log registrou a criação, mas nenhuma regra de correlação disparou, o resultado é só telemetria dupla sem correlação, e o produto é a regra de correlação no backlog. Se o audit log não chegou ao SIEM, o gap é de coleta, e o diagnóstico começa pela política de audit e pelo coletor. O desfecho completo, alerta de runtime, alerta de audit e correlação, é a meta do cenário na rodada.

6. Leitura da Telemetria: Audit Logs e Falco

A leitura disciplinada dos audit logs segue três campos que caracterizam qualquer chamada: identidade, ação e resposta. As detecções de plano de controle exploram combinações incomuns desses campos, como list de secrets por SA que nunca leu secrets, create de pod com privileged true por identidade humana, ou rajada de verbos de descoberta em janela curta. A emulação existe para fornecer esses padrões em condições controladas, e a consulta do cenário anterior ilustra o formato mínimo de verificação.

No plano de dados, as regras do Falco traduzem syscalls em eventos de segurança com identidade de namespace e pod, e o exemplo a seguir mostra uma regra didática de container privilegiado que o cenário deve disparar.

- rule: Container privilegiado criado em namespace de lab
  desc: Detecta execução de container com privileged true fora de janela de manutenção
  condition: container and container.privileged = true and k8s.ns.name = "pt-lab"
  output: "container privilegiado (ns=%k8s.ns.name pod=%k8s.pod.name imagem=%container.image.repository)"
  priority: WARNING
  tags: [container, lab]

A correlação entre as camadas é onde a maturidade aparece. Um audit log de create pod privilegiado sem runtime correspondente indica que o pod não chegou a executar, talvez bloqueado por admission controller, e um runtime de container privilegiado sem audit log correspondente indica gap de coleta do plano de controle. A emulação controlada é a única forma confiável de calibrar essas correlações, porque fornece a linha do tempo exata dos dois lados.

7. Erros Comuns e Pontos de Atenção

• Rodar a emulação no cluster de produção por não haver cluster de teste, transformando o exercício de validação no risco que ele deveria medir; cluster dedicado é requisito inegociável.
• Deixar pods de teste com restartPolicy padrão e sem TTL, acumulando pods residuais que geram telemetria falsa nas rodadas seguintes; limpeza por rótulo com verificação é parte do teste.
• Usar service account com privilégio amplo nos testes e esquecer de removê-la, deixando credencial ativa no cluster; SA de teste nasce e morre na rodada.
• Configurar política de audit que registra apenas metadados, tornando impossível distinguir criação normal de pod de criação de pod privilegiado; riqueza de telemetria é pré-requisito.
• Executar hostPath apontando para a raiz do nó com escrita, mesmo em lab, criando risco real de dano ao nó; paths de teste são criados para o teste.
• Medir apenas a camada de runtime ou apenas a de audit, perdendo a correlação que é o objetivo real da detecção madura em Kubernetes.

8. Integração com o Restante da Biblioteca

Os resultados dos cenários de Kubernetes alimentam o índice e o painel da pasta 03 com a mesma ficha de resultado das demais rodadas, e as técnicas testadas se somam ao conjunto dos atores que atacam ambientes cloud-native. O hunting em containers do Capítulo 08 fornece as queries de caça sobre a mesma telemetria, e os gaps que a emulação expõe viram hipóteses de caça ou requisitos de regra no fluxo da engenharia de detecção. O controle PRT.4 do Capítulo 15 usa os resultados como evidência de que o monitoramento de containers responde de fato.

No quadro do capítulo, a nota completa o purple teaming em cloud iniciado na identidade do Azure, cobrindo o plano de dados e de controle dos clusters, e a validação em CI/CD da próxima nota é o complemento natural, porque a maior parte das mudanças em Kubernetes chega por pipeline. A combinação das três notas cobre a superfície cloud-native com o mesmo regime contínuo de teste, registro e medição.