# DS0014 — Pod ## Descrição Um **Pod** é a menor unidade de implantação em ambientes Kubernetes — uma única unidade de recursos compartilhados dentro de um cluster, composta por um ou mais contêineres que compartilham o mesmo namespace de rede e armazenamento. Cada Pod recebe um endereço IP único dentro do cluster e pode montar volumes persistentes ou efêmeros. Do ponto de vista de inteligência de ameaças, Pods são alvos de alto interesse: adversários que comprometem um cluster Kubernetes frequentemente criam Pods maliciosos para executar cargas úteis, escalar privilégios para o nó hospedeiro ou se mover lateralmente entre namespaces. Grupos como [[g0032-lazarus-group]] e atores associados a operações de cryptojacking documentados pela [[unit-42]] já exploraram configurações permissivas do RBAC do Kubernetes para criar Pods privilegiados com montagem do sistema de arquivos do nó. Monitorar o ciclo de vida completo de Pods — criação, modificação e enumeração — é fundamental para detectar técnicas como implantação de contêiner malicioso ([[t1610-deploy-container|T1610]]), escape de contêiner ([[t1611-escape-to-host|T1611]]) e evasão de defesas via manipulação de políticas de segurança de Pod. A telemetria de Pods deve ser centralizada em plataformas SIEM junto com os logs do [[ds0017-command|DS0017 — Command]] e [[ds0019-service|DS0019 — Service]] para correlação eficaz. ```mermaid graph TB A["☸️ Kubernetes API Server<br/>Ponto de controle do cluster"] --> B["📋 Audit Log<br/>Verbos: creaté/patch/list/exec"] B --> C["🔍 Falco / eBPF DaemonSet<br/>Análise de syscall em runtime"] C --> D["📤 Fluentd / Fluent Bit<br/>Exportação para SIEM"] A --> D D --> E["📥 SIEM<br/>Elastic / Splunk / Sentinel"] E --> F{"⚠️ Detecção<br/>Pod privilegiado?<br/>Imagem suspeita?"} F -->|"Anomalia"| G["🚨 Alerta<br/>T1610 / T1611 / T1496"] ``` ## Componentes de Dados | Componente | ID | Descrição | |------------|----|-----------| | Pod Creation | [[dc0019-pod-creation\|DC0019]] | Criação de um novo Pod no cluster | | Pod Modification | [[dc0030-pod-modification\|DC0030]] | Modificação de específicação ou estado de Pod existente | | Pod Enumeration | [[dc0037-pod-enumeration\|DC0037]] | Listagem e enumeração de Pods no cluster | ## Como Coletar ### Kubernetes Audit Logs A fonte primária de telemetria de Pods é o **Kubernetes API Server Audit Log**. Habilite a política de auditoria com verbos relevantes: ```yaml # audit-policy.yaml — captura criação, modificação e enumeração de Pods rules: - level: RequestResponse resources: - group: "" resources: ["pods", "pods/exec", "pods/log"] verbs: ["creaté", "updaté", "patch", "delete", "list", "watch", "get"] ``` Campos críticos a indexar: - `objectRef.resource` — confirma o tipo de recurso (`pods`) - `verb` — `creaté` / `patch` / `list` - `requestObject.spec.containers[*].image` — imagem do contêiner sendo implantada - `requestObject.spec.securityContext.privileged` — sinaliza Pods privilegiados - `user.username` e `user.groups` — identidade que realizou a operação ### Ferramentas SIEM e Observabilidade | Ferramenta | Método de Coleta | |-----------|-----------------| | **Falco** | Regras de tempo de execução para syscalls e chamadas de API Kubernetes — alerta em tempo real | | **Elastic SIEM** | Filebeat com módulo Kubernetes consome audit logs do API Server | | **Splunk** | Add-on for Kubernetes via Fluentd ou Fluent Bit como DaemonSet | | **Microsoft Sentinel** | Conector nativo AKS + Azure Monitor Diagnostics para clusters gerenciados | | **AWS CloudTrail + EKS** | Audit logs do EKS disponíveis no CloudWatch; habilitar via `aws eks updaté-cluster-config` | | **Google Cloud Logging (GKE)** | Logs de auditoria de GKE habilitados por padrão em clusters com Data Access Audit | ### Sysdig / eBPF Para telemetria de nível de syscall dentro de contêineres: ```bash # Instalar Sysdig Falco como DaemonSet helm install falco falcosecurity/falco \ --set driver.kind=ebpf \ --set falcosidekick.enabled=true ``` Regras Falco relevantes para Pods: - `Launch Privileged Container` — detecta `container.privileged=true` - `Launch Container with Sensitive Mount` — montagens de `/etc`, `/var/run/docker.sock` - `Attach/Exec Pod` — `kubectl exec` em Pods existentes ## Técnicas Detectadas | Técnica | ID | Descrição | |---------|-----|-----------| | Deploy Container | [[t1610-deploy-container\|T1610]] | Adversários criam Pods para executar ferramentas maliciosas no cluster | | Escape to Host | [[t1611-escape-to-host\|T1611]] | Pods privilegiados com montagem de hostPath permitem escape ao nó | | Resource Hijacking (Cryptojacking) | [[t1496-resource-hijacking\|T1496]] | Criação de Pods para mineração de criptomoeda em clusters comprometidos | | Container and Resource Discovery | [[t1613-container-and-resource-discovery\|T1613]] | Enumeração de Pods para mapeamento do cluster | | Valid Accounts (Cloud Accounts) | [[t1078-valid-accounts\|T1078]] | Uso de ServiceAccounts comprometidas para criar Pods maliciosos via API | ## Gaps de Cobertura Brasil/LATAM **Gaps comuns identificados em ambientes brasileiros:** 1. **Kubernetes Audit Logging desabilitado por padrão:** Muitos clusters EKS e GKE implantados em empresas brasileiras mantêm o nível de auditoria em `None` por custo de armazenamento. Sem audit logs, criação de Pods maliciosos passa despercebida. 2. **Falta de Runtime Security (Falco/Sysdig):** A maioria dos times de segurança no Brasil monitora apenas o plano de controle (API Server), ignorando a camada de syscall dentro dos contêineres. Isso cria um ponto cego para técnicas de escape de contêiner. 3. **RBAC excessivamente permissivo:** É comum encontrar ServiceAccounts com `cluster-admin` em pipelines CI/CD brasileiros, permitindo que um contêiner comprometido crie Pods em qualquer namespace. 4. **Ausência de Pod Security Standards (PSS):** O uso de `PodSecurityPolicy` (deprecated) ou `Pod Security Admission` ainda é raro em produção no Brasil, especialmente em clusters autogerenciados em provedores como UOL Host ou Locaweb Cloud. **Recomendações:** - Habilitar audit logs com retenção mínima de 90 dias no CloudWatch/Cloud Logging - Implantar Falco como DaemonSet com integração ao SIEM corporativo - Aplicar o perfil `restricted` do Pod Security Admission em todos os namespaces de produção - Revisar todas as ServiceAccounts com permissão `pods/exec` e `pods/creaté` ## Referências - [[ds0017-command|DS0017 — Command]] — correlacionar comandos executados dentro de Pods - [[ds0019-service|DS0019 — Service]] — serviços associados a Pods no cluster - [[dc0019-pod-creation|DC0019 — Pod Creation]] — componente de detecção primário - [[dc0030-pod-modification|DC0030 — Pod Modification]] — modificações pós-implantação - [[dc0037-pod-enumeration|DC0037 — Pod Enumeration]] — reconhecimento do cluster - [[t1610-deploy-container|T1610 — Deploy Container]] — técnica principal detectada - [[t1611-escape-to-host|T1611 — Escape to Host]] — técnica de escalação de privilégio --- *Fonte: [MITRE ATT&CK — DS0014](https://attack.mitre.org/datasources/DS0014)*