OWASP Kubernetes Top 10 (2025), mão na massa

Um capture-the-flag baseado no OWASP Kubernetes Top 10 — 2025. Você foi contratado para fazer um red team na NimbusMart, uma empresa fictícia de e-commerce cujo cluster cresceu mais rápido que sua segurança. Dez desafios, um por risco OWASP (mais um bônus) — explore cada vulnerabilidade, capture a flag, então aplique a correção e prove com o verificador.

A bíblia do universo (empresa, serviços, namespaces, esquema de flags) está em labs/NIMBUSMART.md.

Tudo roda localmente no kind. Nunca execute os manifestos vulneráveis em um cluster real.

Construído por @hac01.

O que isso cobre

Isto não é uma apresentação de slides — é um cluster Kubernetes funcional e propositalmente vulnerável, mais as ferramentas para atacá-lo, corrigi-lo e verificar a correção. Através dos onze desafios, você coloca a mão na massa com:

• Segurança de containers e nós — pods privilegiados, montagens hostPath e fuga de nós (K01).
• RBAC e autorização — ClusterRoles com curingas, ServiceAccounts com escopo excessivo, e como um único token roubado alcança todos os segredos (K02, K09).
• Gerenciamento de segredos — chaves de API codificadas em env/ConfigMaps e alternativas mais seguras (K03).
• Controle de admissão e políticas — o que escapa quando nada impõe regras em todo o cluster, e como Pod Security Admission / mecanismos de política param isso (K04).
• Segmentação de rede — redes planas de pods vs. bloqueio com NetworkPolicy (K05).
• Componentes expostos — dashboards e APIs internas publicadas via NodePort (K06).
• Higiene de componentes do cluster — tokens padrão, cotas ausentes, versões desatualizadas/vulneráveis (K07).
• Movimento lateral cluster-para-nuvem — um pod acessando o endpoint de metadados do nó (IMDS) para roubar credenciais da nuvem (K08).
• Autenticação — acesso anônimo à API e tokens padrão montados em excesso (K09).
• Logging e monitoramento — detectar (ou não) exfiltração silenciosa de dados, e por que uma trilha de auditoria é importante (K10).
• Supply chain — imagens :latest não confiáveis e mutáveis enviadas para produção (bônus).

Para cada desafio, você recebe:

• Um briefing da missão — o cenário NimbusMart, seu ponto de entrada e o objetivo.
• Uma flag a capturar — alcançável apenas realizando a exploração (no nó, em outro namespace, pela rede). Submeta-a no aplicativo web; o placar acompanha seu progresso e pontos (localStorage do navegador).
• Dicas progressivas e um guia completo (spoiler) — dicas primeiro, solução completa quando quiser.
• Uma visão detalhada — qual é a fraqueza, como os atacantes a abusam, impacto, causas raiz.
• Um guia de defesa — correções concretas e uma checklist de boas práticas.
• Um verificador automatizado — um binário Go que escaneia seu cluster e confirma, por risco, se a correção se mantém.

Pré-requisitos

Instale estes antes de começar. O script de configuração verifica os quatro primeiros e falha rapidamente com uma mensagem clara se algum estiver faltando.

Comandos brew são para macOS. No Linux, use seu gerenciador de pacotes ou as instruções dos links oficiais fornecidas.

Início rápido (recomendado) — tudo dentro de um cluster

O aplicativo web, um terminal no navegador e o verificador podem todos executar dentro do cluster kind. Um comando levanta tudo e imprime a URL:

./setup.sh          # ou: make up
#   - cria o cluster kind, constrói e carrega imagens, faz deploy, aguarda ficar pronto
#   - Web app:  http://localhost:30090
#   - Terminal: o botão 'Terminal' no aplicativo web

./setup.sh (re)cria o cluster com os mapeamentos de porta corretos, constrói as duas imagens (nimbusmart-ctf-web, nimbusmart-ctf-terminal), carrega-as no kind e aplica deploy/. Na primeira execução, baixa as imagens base e leva ~1-2 minutos.

./setup.sh            # cluster novo + plataforma completa (apaga qualquer cluster 'owasp-labs' antigo)
./setup.sh --keep     # reutiliza um cluster 'owasp-labs' existente, se presente

Depois abra http://localhost:30090, escolha um desafio e use o botão Terminal no navegador para comandar o cluster.

O pod do terminal executa como uma ServiceAccount cluster-admin, então o terminal no navegador comanda este mesmo cluster — execute kubectl apply -f labs/... e owasp-k8s-checker --check kNN ali mesmo.

Aviso: o terminal no navegador é efetivamente cluster-admin sobre um WebSocket. É seguro apenas porque está vinculado ao seu cluster kind local e descartável no localhost. Nunca exponha as portas 30080/30090/30091 a uma rede não confiável.

Desmontar

kind delete cluster --name owasp-labs      # ou: make cluster-down

Estrutura do repositório

.
├── setup.sh         Inicialização em um comando (cluster + imagens + deploy)
├── Makefile         Alvos de conveniência — execute `make help` para listá-los
├── web/             Aplicativo Next.js + React (tema branco/roxo) — a interface
├── labs/            Manifestos K8s reais por risco (vulnerable.yaml + fixed.yaml + README)
│   ├── NIMBUSMART.md        Bíblia do universo: empresa, namespaces, esquema de flags
│   └── kind-cluster.yaml    Configuração compartilhada do cluster local (mapeamento de portas)
├── deploy/          Manifestos da plataforma dentro do cluster (web + terminal + RBAC) + build.sh
├── terminal-server/ Backend WebSocket para o terminal no navegador
└── checker/         Binário Go que valida um cluster contra o Top 10

Alvos úteis do make (make help mostra todos):

O OWASP Kubernetes Top 10 — 2025

Cada desafio é uma fraqueza real no cluster da NimbusMart — escolha um alvo, explore-o, capture a flag, então corrija e prove a correção com o verificador.

O que mudou de 2022: autorização (era RBAC) ampliada; segredos, rede, autenticação e logging reordenados; Componentes Excessivamente Expostos (K06) e Movimento Lateral do Cluster para a Nuvem (K08) adicionados; componentes mal configurados e desatualizados mesclados em K07; Cadeia de Suprimento movida para um desafio bônus. Veja labs/NIMBUSMART.md para o mapa completo desafio-serviço-vulnerabilidade, dificuldade e pontos (2000 em 10 desafios, +300 bônus).

Fluxo de trabalho manual / dev (sem a plataforma dentro do cluster)

Prefere executar a interface localmente e comandar os laboratórios pelo seu próprio shell? Você pode montar as peças manualmente.

1. Execute o aplicativo web localmente

cd web
npm install
npm run dev
# abra http://localhost:3000       (ou: make web)

O backend do terminal é executado separadamente na :30091 usando seu ~/.kube/config:

make terminal-local

2. Crie um cluster de laboratório

kind create cluster --config labs/kind-cluster.yaml    # ou: make cluster
kubectl config use-context kind-owasp-labs

3. Jogue um desafio

Cada desafio tem seu próprio README, mas o padrão é o mesmo:

# alguns desafios primeiro preparam um alvo (um arquivo no nó, um segredo de operações, ...)
kubectl apply -f labs/k01-insecure-workload/setup.yaml       # apenas se existir

# faça deploy do recurso vulnerável e explore-o para capturar a flag
kubectl apply -f labs/k01-insecure-workload/vulnerable.yaml
# ...siga o briefing da missão / dicas no aplicativo web, pegue FLAG{...}, submeta-a...

# aplique a versão corrigida e confirme que o caminho da flag foi fechado
kubectl delete -f labs/k01-insecure-workload/vulnerable.yaml
kubectl apply  -f labs/k01-insecure-workload/fixed.yaml

Reinicie tudo entre os desafios com make clean-labs.

4. Verifique com o verificador

cd checker
go run . --list            # mostra todos os verificadores
go run . --check k01       # executa um único verificador
go run . --all             # escaneia todo o cluster
go run . --all --json      # formato legível por máquina (para CI)
go run . --all -n apps     # limita a um namespace

O verificador sai com código diferente de zero se alguma verificação falhar, então pode ser usado como gate de CI.

Construa um binário independente:

cd checker
go build -o owasp-k8s-checker .    # ou: make checker
./owasp-k8s-checker --all

Como o verificador se relaciona com os laboratórios

Cada checker/checks/kNN.go valida o mesmo controle que o laboratório correspondente ensina. Faça deploy do fixed.yaml, execute go run . --check kNN, e você deve ver PASS. Faça deploy do vulnerable.yaml e a mesma verificação relata as descobertas específicas.

Segurança: os manifestos vulneráveis são propositalmente exploráveis. Use apenas um cluster local descartável kind/minikube. Exclua-o quando terminar: kind delete cluster --name owasp-labs.