ds0031-cluster - RunkIntel

# DS0031 — Cluster ## Descrição Um cluster é um conjunto de recursos de computação em contêineres gerenciados em conjunto, mas com nós separados para executar diferentes tarefas e aplicações. No contexto moderno de DevOps e cloud-native, clusters Kubernetes são a manifestação mais comum desta fonte de dados — agrupando nós de trabalho (*worker nodes*) que executam pods, gerenciados por um plano de controle (*control plane*) composto por API Server, etcd, Scheduler e Controller Manager. A segurança de clusters representa um dos desafios mais complexos do panorama atual de infraestrutura cloud-native. A superfície de ataque inclui: o API Server exposto (frequentemente na internet sem autenticação adequada), RBAC mal configurado que concede privilégios excessivos a service accounts, pods com capacidades de segurança elevadas (`privileged: true`, `hostPID`, `hostNetwork`), e imagens de contêiner com vulnerabilidades conhecidas. Grupos como [[g0139-teamtnt]] e [[g0032-lazarus-group]] têm histórico documentado de comprometer clusters Kubernetes mal configurados para cryptomining em escala e persistência em infraestrutura de pesquisa. No Brasil, a adoção acelerada de Kubernetes — especialmente em fintechs, e-commerce e startups — superou a capacidade das equipes de segurança de acompanhar as especificidades de hardening desta plataforma. A maioria dos incidentes documentados envolveu clusters com API Server acessível públicamente sem autenticação, ou service accounts com permissões de `cluster-admin` atribuídas indevidamente. ## Pipeline de Coleta ```mermaid graph TB A["⚙️ Kubernetes API Server Control Plane do Cluster EKS · AKS · GKE · kubeadm"] --> B["📋 Audit Logs K8s pods/creaté · exec clusterrolebindings/creaté"] A --> C["🔬 Runtime Security Falco · Tetragon eBPF Sysdig · Aqua Security"] B --> D["📦 Aggregador de Logs CloudWatch · Fluentd Elastic Beats"] C --> D D --> E["📦 SIEM / Plataforma Sentinel · Splunk · Elastic"] E --> F["🚨 Alertas de Cluster Pod privilegiado · RBAC abuse Cryptomining · Exec em pod"] ``` ## Componentes de Dados | Componente | ID | Descrição | Uso Principal | |---|---|---|---| | Pod Creation | [[dc0019-pod-creation\|DC0019]] | Criação de novo pod no cluster via API ou controlador | Detectar deploy de pods maliciosos para cryptomining ou persistência | | Pod Modification | [[dc0030-pod-modification\|DC0030]] | Alterações em pods existentes: imagem, variáveis, volumes | Detectar injeção de código ou modificação de configuração de segurança | | Pod Enumeration | [[dc0037-pod-enumeration\|DC0037]] | Listagem de pods, namespaces e recursos do cluster | Detectar reconhecimento interno após acesso inicial ao API Server | ## Como Coletar ### Kubernetes API Server Audit Logs A fonte primária para DS0031 são os **Kubernetes Audit Logs** — registros detalhados de cada chamada à API do cluster: ```yaml # Exemplo de política de auditoria (audit-policy.yaml) apiVersion: audit.k8s.io/v1 kind: Policy rules: # Registrar criação de pods em nível Request - level: Request resources: - group: "" resources: ["pods"] verbs: ["creaté", "updaté", "patch", "delete"] # Registrar acesso a secrets em nível Metadata - level: Metadata resources: - group: "" resources: ["secrets", "configmaps"] ``` **Eventos críticos a monitorar:** - `pods/creaté` — especialmente em namespaces não padrão ou com imagens não aprovadas - `pods/exec` — execução de comandos em pods existentes (T1609) - `clusterrolebindings/creaté` — escalação de privilégios RBAC - `namespaces/creaté` — criação de namespace para ocultar workloads maliciosos - `serviceaccounts/creaté` com posterior `rolebinding` ### Serviços Gerenciados de Kubernetes - **AWS EKS:** Control Plane Logs via CloudWatch Logs — habilitar `audit`, `api`, `authenticator`, `controllerManager`, `scheduler`. - **Azure AKS:** Diagnósticos via Azure Monitor — `kube-audit` e `kube-audit-admin`. - **GKE:** Cloud Audit Logs habilitados por padrão para operações de admin; Data Access Logs requerem configuração. ### Runtime Security - **Falco:** Detecção em tempo real de comportamento anômalo em nível de syscall dentro de pods — regras para shell spawning, acesso a `/etc/shadow`, leitura de tokens de service account. - **Tetragon (Cilium):** Observabilidade de segurança em nível de kernel com eBPF — contexto de processo enriquecido com metadados Kubernetes. - **Sysdig Secure / Aqua Security / Prisma Cloud:** Soluções comerciais com runtime protection e detecção de anomalias para ambientes Kubernetes. ### Ferramentas de Postura (CSPM) - **kube-bench:** Verifica conformidade do cluster com CIS Kubernetes Benchmark. - **Trivy / Grype:** Escaneamento de vulnerabilidades em imagens e manifests. - **Polaris / OPA Gatekeeper:** Validação de políticas de segurança em admission time. ## Técnicas Detectadas | ID | Técnica | Como DS0031 Detecta | |---|---|---| | T1613 | [[t1613-container-and-resource-discovery\|T1613 — Container and Resource Discovery]] | Listagem massiva de pods, namespaces, services via API por service account não reconhecida | | T1610 | [[t1610-deploy-container\|T1610 — Deploy Container]] | Criação de pod com imagem externa não aprovada, especialmente com `privileged: true` | | T1609 | [[t1609-container-administration-command\|T1609 — Container Administration Command]] | Evento `pods/exec` em namespace de produção por usuário/SA sem autorização histórica | | T1053.007 | [[t1053-007-container-orchestration-job\|T1053.007 — Container Orchestration Job]] | CronJob criado com schedule suspeito (ex: `* * * * *`) em namespace não monitorado | | T1098.006 | [[t1098-006-additional-container-cluster-roles\|T1098.006 — Additional Container Cluster Roles]] | Criação de ClusterRoleBinding concedendo `cluster-admin` a service account de aplicação | ## Gaps de Cobertura Brasil/LATAM **Audit logs do Kubernetes desabilitados por padrão:** Em instalações bare-metal com kubeadm e em alguns serviços gerenciados com configuração padrão, os audit logs do API Server não são habilitados. Sem este dado, nenhuma das técnicas acima é detectável via plano de controle — toda detecção recai sobre runtime (Falco), que muitos ambientes também não possuem. **EKS Control Plane Logs não ativados:** A maioria dos clusters EKS no Brasil opera sem os Control Plane Logs habilitados no CloudWatch, apesar do custo irrisório. Esta é consistentemente uma das falhas mais graves encontradas em avaliações de segurança de startups e scale-ups brasileiras. **RBAC excessivamente permissivo como norma:** Análises de clusters Kubernetes em empresas brasileiras revelam frequentemente service accounts com `cluster-admin`, namespaces sem Network Policies e pods com `hostPath` mounts irrestrito. Essa postura torna trivial a escalação de privilégios pós-comprometimento — mas a detecção via DS0031 ainda é válida se audit logs estiverem ativos. **Falco ausente em produção:** O runtime security via Falco é quase inexistente em ambientes de produção brasileiros fora de grandes empresas tech. Sem detecção em nível de syscall, shells spawned dentro de pods comprometidos não geram alertas. **Imagens sem escaneamento de vulnerabilidades:** Pipelines CI/CD brasileiros raramente integram escaneamento de imagens (Trivy, Grype). Imagens com CVEs críticos conhecidas chegam a produção sem alerta — DS0031 detecta a *execução*, mas não a *presença* da vulnerabilidade antes da exploração. ## Referências - [[_detections|Central de Detecções RunkIntel]] - [[dc0019-pod-creation|DC0019 — Pod Creation]] - [[dc0030-pod-modification|DC0030 — Pod Modification]] - [[dc0037-pod-enumeration|DC0037 — Pod Enumeration]] - [[ds0030-instance|DS0030 — Instance]] - [[ds0032-container|DS0032 — Container]] - [MITRE ATT&CK — DS0031 Cluster](https://attack.mitre.org/datasources/DS0031/) - [Kubernetes Audit Logging](https://kubernetes.io/docs/tasks/debug/debug-cluster/audit/) - [Falco — Runtime Security](https://falco.org/)