Modelo de ameaças do Kubernetes

O Kubernetes orquestra contêineres em muitos nós. Ele centraliza segredos, redes e recursos computacionais, portanto comprometer o cluster pode significar comprometer cada carga de trabalho executada por ele.

• Um único servidor da API controla todo o cluster.
• Os nós executam lado a lado as cargas de trabalho de vários locatários.
• Configurações incorretas são muito mais comuns do que CVEs no núcleo.

Para modelar ameaças, conheça os componentes.

• Plano de controle: servidor da API, etcd, agendador e gerenciador de controladores.
• Nós: kubelet, ambiente de execução de contêineres, kube-proxy e pods.
• etcd armazena todo o estado e os segredos do cluster.

O servidor da API é o único ponto de entrada; o etcd é o ativo de dados mais valioso.

Os ataques têm como alvo camadas distintas.

• Externa: servidor da API, painéis e entrada expostos.
• Carga de trabalho: uma aplicação comprometida dentro de um pod.
• Identidade: tokens de contas de serviço e RBAC.
• Nó: API do kubelet e escape do contêiner para o host.
• Cadeia de suprimentos: imagens e dependências maliciosas.

Um servidor da API acessível pela internet ou um kubelet com autenticação fraca é um caminho direto para assumir o controle do cluster.

• Acesso anônimo ativado no servidor da API.
• API de leitura/gravação do kubelet (porta 10250) exposta.
• Painel do Kubernetes aberto com vinculação administrativa.

O ponto de entrada mais comum é uma RCE em uma aplicação em execução em um pod. De dentro de um pod, os invasores encontram:

• Um token de conta de serviço montado em /var/run/secrets/....
• Serviços internos acessíveis (sem política de rede).
• O servidor da API, geralmente resolvível como kubernetes.default.

Sair de um contêiner para chegar ao nó permite acessar todas as cargas de trabalho naquele host.

• Contêineres privilegiados podem acessar dispositivos do host e escapar.
• As montagens hostPID/hostNetwork/hostPath ampliam o impacto.
• Um soquete do Docker montado permite iniciar um contêiner privilegiado.
• Capacidades perigosas (SYS_ADMIN) permitem o escape.

O etcd contém todo o estado do cluster, incluindo os Segredos, que por padrão são apenas codificados em base64. O acesso direto ao etcd (frequentemente não autenticado em clusters com configuração incorreta) expõe todos os segredos.

Depois de entrar, os invasores fazem o pivô usando a identidade e a rede do cluster.

• Uma conta de serviço permissiva permite criar pods privilegiados.
• Redes de pods sem segmentação (sem NetworkPolicy) permitem alcançar qualquer serviço.
• Agendar um pod em um nó-alvo permite comprometer o nó.

Em clusters gerenciados (EKS/GKE/AKS), os pods podem alcançar o serviço de metadados da nuvem do nó e roubar as credenciais IAM/de função do nó, fazendo a ponte entre o comprometimento do cluster e a conta da nuvem.

As defesas incluem IMDSv2, o bloqueio dos metadados na camada de rede e o uso da identidade da carga de trabalho em vez de funções de nó.

As ferramentas automatizam a avaliação de ameaças ao cluster.

• kube-hunter investiga componentes expostos.
• kube-bench verifica a conformidade com o referencial CIS.
• Peirates / kubeletctl testam caminhos de ataque dentro do cluster.

O modelo de ameaças aponta prioridades defensivas claras: proteger o servidor da API, restringir o RBAC, isolar os pods, fortalecer os nós e proteger a cadeia de suprimentos. As próximas lições detalham cada uma.

Durante os testes, ataque apenas clusters para os quais você tenha autorização e evite desestabilizar as cargas de trabalho de produção.

Você mapeou onde os clusters Kubernetes são atacados.

• O servidor da API e o etcd são os alvos centrais e de maior valor.
• Pontos de apoio dentro de pods aproveitam tokens SA montados e redes sem segmentação.
• Pods privilegiados ou com hostPath permitem o escape do contêiner para o nó.
• Clusters gerenciados correm o risco de pivotamento para a nuvem baseado em metadados.

A seguir: RBAC e contas de serviço.