Equipes que operam Kubernetes costumam descobrir falhas de configuração só depois do incidente. O kube-bench aplica automaticamente as verificações do CIS Kubernetes Benchmark contra um cluster ou nó e devolve um relatório de conformidade que serve de base para decisão técnica. Ele não corrige nada: a ferramenta aponta o que desvia do padrão, e a decisão sobre o que ajustar — e em que ordem — continua sendo da engenharia defensiva. A ação prioritária é rodar a auditoria antes de qualquer mudança, comparar o resultado com a arquitetura real e só então planejar as correções.

O CIS Kubernetes Benchmark é publicado pelo Center for Internet Security como guia de configuração segura desenvolvido em processo de consenso comunitário, e está em versão 2.1.0 para Kubernetes autogerenciado, além de variantes por plataforma gerenciada. O kube-bench implementa esse benchmark o mais fielmente possível, com testes descritos em arquivos YAML — o que mantém a ferramenta atualizável conforme o padrão evolui. Antes de subir o scanner, porém, é preciso entender o que ele enxerga e o que foge do alcance dele, para não tratar um relatório parcial como atestado de segurança.

Como preparar a execução

O kube-bench precisa de visão dos processos e arquivos que ele audita: quando roda em pod ou contêiner, exige acesso ao namespace de PID do host e a diretórios onde ficam os arquivos de configuração, como /etc e /var. O repositório fornece um job.yaml pronto — aplica-se com kubectl e o resultado sai nos logs do pod. Em nós gerenciados por você, a execução direta com Docker evita instalar binário no host: monta-se /etc e /var em modo leitura e aponta-se a versão do Kubernetes para que o conjunto correto de testes seja selecionado.

Por padrão, a ferramenta tenta detectar automaticamente a versão do Kubernetes em execução e mapeá-la para a versão correspondente do CIS Benchmark, além de identificar os componentes ativos no nó para escolher quais testes aplicar — por exemplo, rodar as verificações de nó de controle apenas onde há um API server. A versão do Kubernetes e a versão do benchmark não têm mapeamento um-para-um, então em clusters fora do padrão convém fixar a versão explicitamente e registrar essa decisão junto ao relatório.

Requisitos de execução em uma linha de verificação:

  • Permissão de root ou equivalente para ler todas as configurações auditadas;
  • Namespace de PID do host e montagem somente leitura de /etc e /var quando rodar em contêiner;
  • Versão do benchmark fixada quando o cluster usa distribuição que autodetecção não reconhece;
  • Relatório arquivado com data, versão da ferramenta e versão do benchmark usada.

Como ler o relatório

A saída organiza os resultados por seção do benchmark, com marcações de aprovado (PASS), reprovado (FAIL), advertência (WARN) e informativo (INFO). Um FAIL indica desvio de configuração verificável; um WARN costuma indicar verificação que depende de leitura manual, porque o teste não consegue avaliar sozinho — por exemplo, itens cuja prova exige consultar outro nó ou processo fora do alcance do scanner. Ignorar WARNs é o erro mais comum de leitura: eles frequentemente escondem os itens que exigem decisão, não comando.

Um ponto de honestidade técnica: o relatório é uma fotografia da configuração no momento da execução. Ele não mede exposição de rede, não avalia a cadeia de fornecimento das imagens nem substitui testes de intrusão. Compare o resultado com a arquitetura declarada do cluster e registre justificativa para cada item que a equipe decidir aceitar como risco conhecido — o benchmark é referência, não contrato automático.

Onde a ferramenta não alcança

O limite mais importante aparece em clusters gerenciados: é impossível inspecionar os nós de controle de serviços como GKE, EKS, AKS e ACK com o kube-bench, porque não há acesso a esses nós — ainda assim, é possível usar a ferramenta para auditar a configuração dos nós de trabalho nesses ambientes. Em clusters gerenciados, as variantes do benchmark por plataforma (EKS 2.0.0, AKS 2.0.0, GKE 2.0.0, entre outras publicadas pelo CIS) cobrem parte do plano de controle por meio de controles gerenciados, e cada fornecedor documenta o que permanece fora de alcance do cliente.

Há também limite operacional: o job roda com privilégios elevados e acesso amplo ao host. Isso torna o scanner um ativo sensível — restrinja a execução a pipelines controlados ou a operadores autorizados, e nunca exponha o relatório bruto, que revela topologia e configuração interna, em canais abertos.

Prioridades depois do relatório

P1 — correções de plano de controle que afetam autenticação, autorização e exposição do API server; itens que o cluster responde como FAIL em seções de API Server e RBAC entram primeiro na fila.

P2 — ajustes de nó e de política que reduzem risco sem urgência imediata: permissões de arquivos de configuração, flags de kubelet e NetworkPolicy ausente, este último um reforço natural depois da segmentação de rede.

Antes de mexer em qualquer flag, registre o comportamento esperado e teste em ambiente de não produção: boa parte das correções de benchmark afeta componentes que sustentam cargas em execução, e uma mudança sem rollback planejado cria incidente em nome da conformidade. Itens legados que não fazem sentido na sua arquitetura devem receber aceitação formal documentada, não silêncio.

Critérios para adotar no pipeline

Vale rodar kube-bench como etapa periódica e não como evento único: o cluster muda, novas versões de benchmark surgem e a deriva de configuração é gradual. O ecossistema da própria Aqua Security também oferece varredura CIS no Trivy e no Trivy Operator, que podem integrar a checagem à rotina de scanner do cluster. Na comparação de ferramentas de linha de base, considere:

  • Cobertura da versão do Kubernetes que você roda hoje;
  • Suporte a variações por plataforma gerenciada ou distribuição;
  • Facilidade de arquivar e comparar relatórios entre execuções;
  • Custo de execução em produção (privilégios, tempo, interrupção).

Com critérios explícitos, o relatório deixa de ser check-list de auditoria e passa a orientar decisões: o que corrigir, o que aceitar com risco documentado e o que exige mudança de arquitetura. Para as decisões de acesso que o relatório não cobre, a gestão de privilégios e auditoria no RBAC é o complemento natural.

Fontes