Quando uma organização roda centenas ou milhares de contêineres, ela precisa de algo que os orquestre — implante, escale, conecte e gerencie automaticamente. O Kubernetes (frequentemente abreviado K8s) tornou-se o padrão dominante dessa orquestração, e é a espinha dorsal de grande parte da infraestrutura nativa de nuvem. Sua complexidade cria uma superfície de ataque rica, e entendê-la é essencial para o pentest de ambientes modernos. Esta aula cobre a segurança de Kubernetes em nível conceitual. Laboratório com Minikube ou um cluster de teste, sempre.

API server, etcd e o control plane

Comece com uma noção da arquitetura do Kubernetes, porque cada componente é uma superfície. Um cluster Kubernetes tem um control plane (plano de controle) que gerencia tudo, cujo componente central é o API server — o cérebro do cluster, por onde toda operação passa (implantar, modificar, consultar). Há o etcd, o banco de dados que armazena todo o estado e a configuração do cluster (incluindo, frequentemente, segredos). E há os nodes (nós — as máquinas que efetivamente rodam os contêineres), onde os contêineres são agrupados em pods (a menor unidade, um ou mais contêineres juntos). Entender que o API server é o ponto central de controle é crucial: comprometê-lo é comprometer o cluster inteiro, e boa parte da segurança de Kubernetes gira em torno de protegê-lo e controlar quem pode fazer o quê através dele.

A ampla superfície de ataque

A superfície de ataque de Kubernetes é ampla justamente pela quantidade de componentes e pela complexidade da configuração. Os vetores principais: o API server exposto ou mal protegido (se acessível sem autenticação adequada, é controle direto do cluster); o etcd exposto (que contém todos os segredos e estado — acessá-lo é catastrófico); os kubelets (o agente em cada node) mal protegidos; dashboards de Kubernetes expostos sem autenticação (houve comprometimentos famosos assim); e a configuração insegura em geral. Como no Docker, a complexidade do Kubernetes faz com que configurações inseguras sejam a fonte mais comum de comprometimento — há tantas opções e componentes que erros de configuração são frequentes.

RBAC e as service accounts

O conceito de segurança mais importante do Kubernetes é o RBAC (Role-Based Access Control, Controle de Acesso Baseado em Papéis). Como o API server controla tudo, é vital controlar quem pode fazer o quê — e o RBAC é o mecanismo que define isso, atribuindo permissões a usuários, grupos e (crucialmente) a service accounts (contas de serviço usadas pelos próprios pods). O RBAC mal configurado é um vetor central: permissões excessivas concedidas a uma conta ou a um pod permitem que um atacante que comprometa esse pod escale privilégios dentro do cluster. É a mesma lógica do menor privilégio e do BloodHound do AD (Bloco XI) — mapear e explorar as relações de permissão. Um pod comprometido com uma service account superprivilegiada pode, frequentemente, assumir o controle do cluster; ferramentas de auditoria de RBAC (análogas ao BloodHound) mapeiam esses caminhos de escalação.

O ataque que encadeia do pod ao cluster

O ataque em Kubernetes frequentemente segue um padrão que encadeia conceitos que você já domina. O atacante compromete uma aplicação rodando num pod (via as vulnerabilidades web do Bloco XII, por exemplo). De dentro do pod, ele enumera o ambiente (estou num contêiner? num pod Kubernetes? que service account tenho? que permissões ela dá?). Se a service account do pod tem permissões excessivas (RBAC mal configurado), ele as usa para interagir com o API server e escalar — acessar segredos, criar pods privilegiados, alcançar outros namespaces, e potencialmente comprometer o cluster inteiro. Ele também pode tentar o escape de contêiner (aula Segurança de contêineres e Docker: isolamento e escape) para alcançar o node, e de lá o cluster. É a cadeia comprometimento inicial → enumeração → escalação via permissões → controle do cluster, os mesmos princípios da pós-exploração (Bloco VIII) aplicados ao ambiente Kubernetes. Ferramentas como o kube-hunter (que caça vulnerabilidades num cluster) e o kubectl (a CLI legítima, usada ofensivamente com credenciais comprometidas) são centrais.

A complexidade é inimiga da segurança

O ponto conceitual: o Kubernetes é uma plataforma poderosa e complexa, e a complexidade é inimiga da segurança (a lição da aula Web avançada II: request smuggling, CORS, prototype pollution e race conditions). Ele orquestra enormes ambientes com flexibilidade imensa, mas essa flexibilidade significa incontáveis opções de configuração, muitas com implicações de segurança que são fáceis de errar. O comprometimento de Kubernetes raramente é um único exploit — é a exploração de configurações inseguras acumuladas (RBAC frouxo, componentes expostos, pods privilegiados, segredos mal geridos) que, encadeadas, levam do acesso a um pod ao controle do cluster. Dominar a segurança de Kubernetes é dominar a arte de configurar corretamente um sistema de vasta complexidade — e de encontrar, ofensivamente, os pontos onde essa configuração falhou.

RBAC com menor privilégio

Do lado defensivo, as práticas de segurança de Kubernetes reúnem lições do curso aplicadas a esse contexto: RBAC com menor privilégio rigoroso (a defesa central — conceder a cada conta e pod apenas as permissões estritamente necessárias, especialmente às service accounts); proteger o API server e o etcd (autenticação forte, acesso restrito, criptografia do etcd); não expor dashboards nem componentes desnecessariamente; network policies (segmentação dentro do cluster, limitando a comunicação entre pods — a segmentação da aula Pivoting e tunneling: da máquina comprometida à rede inteira aplicada ao cluster); pod security standards (restringir pods privilegiados e configurações perigosas); gestão adequada de segredos (não em texto claro, usando os mecanismos apropriados); escanear imagens (aula Segurança de contêineres e Docker: isolamento e escape); e auditoria e monitoramento do cluster. Frameworks e benchmarks (o CIS Kubernetes Benchmark) guiam o hardening. A lição: o Kubernetes concentra o controle de vastos ambientes, e protegê-lo exige disciplina de configuração e menor privilégio em cada uma de suas muitas camadas.

Fontes e leituras recomendadas

Exercícios

  1. Qual o papel do API server num cluster Kubernetes, e por que comprometê-lo é tão grave?

    ✓ Resposta:

    O API server é o cérebro do cluster — toda operação (implantar, modificar, consultar) passa por ele. Comprometê-lo é grave porque significa controle sobre todo o cluster: quem controla o API server pode gerenciar todos os recursos, pods, segredos e nodes.

  2. O que é o RBAC, e por que sua má configuração é um vetor central de escalação?

    ✓ Resposta:

    O RBAC (Role-Based Access Control) define quem (usuários, grupos, service accounts) pode fazer o quê no cluster. Sua má configuração é central porque permissões excessivas concedidas a uma conta ou pod permitem que um atacante que comprometa esse pod use essas permissões para escalar — acessar segredos, criar pods privilegiados e comprometer o cluster.

  3. Descreva o padrão típico de ataque em Kubernetes, do comprometimento de um pod ao controle do cluster.

    ✓ Resposta:

    O atacante compromete uma aplicação num pod (ex.: via falha web), enumera o ambiente (contêiner? pod? qual service account e permissões?), e se a service account tem permissões excessivas (RBAC frouxo), usa-as para interagir com o API server e escalar (segredos, pods privilegiados, outros namespaces), podendo também escapar do contêiner para o node — chegando ao controle do cluster.

  4. Por que "a complexidade é inimiga da segurança" se aplica particularmente ao Kubernetes?

    ✓ Resposta:

    Porque o Kubernetes orquestra ambientes enormes com flexibilidade imensa, o que significa incontáveis opções de configuração e componentes, muitos com implicações de segurança fáceis de errar. Os comprometimentos vêm do acúmulo de configurações inseguras (RBAC frouxo, componentes expostos, pods privilegiados) encadeadas, mais do que de um único exploit.

  5. Cite três contramedidas de segurança de Kubernetes, destacando a defesa central.

    ✓ Resposta:

    RBAC com menor privilégio rigoroso (a defesa central), proteger o API server e o etcd, não expor dashboards/componentes, network policies, pod security standards, gestão de segredos, escanear imagens, auditoria. (Três quaisquer, com o RBAC destacado.)