Segurança no Kubernetes: o guia completo

O Kubernetes se tornou a forma padrão de executar aplicações em containers em escala e, com essa onipresença, vem um problema de segurança fácil de subestimar. A segurança no Kubernetes é a prática de proteger seus clusters, os workloads que eles executam e a cadeia de suprimentos de software que os alimenta, ao longo de todo o ciclo de vida, do primeiro commit de um desenvolvedor até um pod atendendo tráfego real. Não é um único controle que você liga. É uma disciplina que toca infraestrutura, código de aplicação, rede, identidade e processos.

Se você é engenheiro de plataforma ou de segurança, provavelmente já sentiu a distância entre a rapidez com que as equipes conseguem entregar no Kubernetes e a dificuldade de saber se o que elas entregaram é seguro. Este guia é a pedra angular do nosso cluster de conteúdo sobre segurança no Kubernetes. Ele percorre o modelo, as razões pelas quais proteger clusters Kubernetes é genuinamente difícil, a superfície de ataque que você está defendendo e as principais áreas de prática, cada uma com um aprofundamento dedicado. O objetivo é um mapa claro e prático das melhores práticas de segurança no Kubernetes que você pode realmente executar com sua equipe.

Uma nota rápida sobre o escopo antes de começarmos. A segurança no Kubernetes é frequentemente discutida como se fosse uma preocupação puramente operacional, algo que a equipe de plataforma configura uma vez e esquece. Na prática, os programas mais fortes a tratam como uma disciplina compartilhada: os desenvolvedores a influenciam pelas imagens e manifests que escrevem, as equipes de plataforma pela configuração do cluster e pelos guardrails, e as equipes de segurança pela política e pela verificação. Este guia foi escrito com esses três públicos em mente, porque as falhas que importam costumam acontecer justamente nas junções entre eles.

O que é segurança no Kubernetes?

A segurança no Kubernetes é o conjunto de controles, configurações e processos que mantêm um ambiente Kubernetes e seus workloads confiáveis. Isso inclui quem pode se comunicar com o cluster e o que pode fazer, como os workloads são isolados uns dos outros, como os dados sensíveis são armazenados e acessados, de onde vêm as imagens de container e como você detecta e responde quando algo dá errado.

Uma forma útil de enquadrar a segurança da orquestração de containers é o modelo de responsabilidade compartilhada. Se você usa um serviço gerenciado de Kubernetes, seu provedor de nuvem protege o hardware subjacente e, dependendo da oferta, partes do control plane. Tudo acima dessa linha, a configuração do seu cluster, seus workloads e seu código, é responsabilidade sua. Interpretar essa linha de forma equivocada é uma das fontes mais comuns de exposição.

Os 4C's da segurança cloud native

A comunidade adotou um modelo em camadas, os 4C's, que descreve a defesa em profundidade de fora para dentro:

• Cloud (ou o datacenter/infraestrutura corporativa): o ambiente em que o cluster roda. Fraquezas aqui, uma role de IAM de nuvem excessivamente permissiva, uma porta de gerenciamento exposta, comprometem tudo o que está acima.
• Cluster: os próprios componentes do Kubernetes, o API server, o etcd, os controllers e as políticas que regem o acesso e o comportamento dos workloads.
• Container: as imagens e os runtimes dos workloads individuais, incluindo o que está dentro da imagem e como o container tem permissão para rodar.
• Code (código): o código da sua própria aplicação e suas dependências, onde vivem as falhas de injeção, a lógica insegura e as bibliotecas vulneráveis.

Cada camada fica dentro da seguinte. Você não consegue proteger a camada de container se a camada de cluster estiver escancarada, e endurecer o cluster de pouco adianta se o seu código entrega uma vulnerabilidade crítica de execução remota de código. A segurança eficaz no Kubernetes atua nas quatro camadas ao mesmo tempo.

Por que a segurança no Kubernetes é difícil

O Kubernetes é poderoso justamente porque é dinâmico, distribuído e altamente configurável. Essas mesmas propriedades o tornam difícil de proteger.

Ele é dinâmico. Pods são criados e destruídos o tempo todo. Um endereço IP que pertencia a um serviço de pagamentos em um minuto pode pertencer a outra coisa no minuto seguinte. Controles tradicionais de perímetro e baseados em host, que pressupõem ativos relativamente estáveis, têm dificuldade em um ambiente onde o tempo de vida médio de um workload se mede em horas ou minutos.

Ele é distribuído. Um cluster é um conjunto de componentes que cooperam, control plane e worker nodes, espalhados por máquinas e frequentemente por zonas de disponibilidade. Há muitas partes móveis e muitas relações de confiança. Uma fraqueza em um componente, digamos um kubelet exposto sem autenticação adequada, pode se tornar um ponto de apoio para o resto.

Ele é inseguro por padrão de maneiras que surpreendem as pessoas. Fora da caixa, o Kubernetes otimiza para colocar os workloads em execução, não para blindá-los. Por padrão, qualquer pod pode se comunicar com qualquer outro pod no cluster, porque não há segmentação de rede até você adicionar network policies. Os containers muitas vezes rodam como root a menos que você o impeça explicitamente. Service accounts podem receber muito mais acesso do que um workload precisa. Os secrets ficam armazenados no etcd codificados em base64, o que é codificação, não criptografia. Nenhum desses padrões é malicioso; eles simplesmente significam que um cluster que você não endureceu deliberadamente é um cluster com falhas reais.

Some a isso o ritmo de mudança, novos nodes, novos workloads, novas dependências todos os dias, e fica claro por que auditorias pontuais não acompanham. A segurança no Kubernetes precisa ser contínua.

A superfície de ataque e o modelo de ameaças do Kubernetes

Para defender um cluster, ajuda pensar como um atacante e enumerar as formas de entrada. A superfície de ataque do Kubernetes é ampla, mas os alvos recorrentes se agrupam em algumas poucas áreas.

O control plane. O API server é a porta da frente para tudo; se um atacante conseguir alcançá-lo com privilégios suficientes, ele efetivamente controla o cluster. O etcd armazena todo o estado do cluster, incluindo secrets, então acesso de leitura ao etcd é catastrófico. Um API server ou endpoint etcd mal protegido ou exposto à internet é um dos achados de mais alta severidade que você pode ter.

Os nodes e o kubelet. Cada worker node roda um kubelet que gerencia os pods naquele node. Um kubelet exposto ou fracamente autenticado pode permitir que um atacante execute comandos dentro de containers ou no próprio node. O comprometimento de um único node pode levar ao comprometimento dos workloads agendados nele.

Workloads e movimentação lateral. Uma vez que um atacante tenha um ponto de apoio em um pod, seja por uma aplicação vulnerável, uma dependência envenenada ou uma credencial vazada, ele busca se mover. RBAC excessivamente permissivo, tokens de service account montados, rede de pods plana e containers rodando com privilégios em excesso, tudo isso facilita a movimentação lateral e a escalada de privilégios.

A cadeia de suprimentos. Cada vez mais, a entrada em um cluster não é um exploit ao vivo, mas uma imagem ou dependência comprometida que você mesmo implantou. Uma imagem base com uma vulnerabilidade crítica conhecida, um pacote typosquatted ou um pipeline de build que puxa artefatos não verificados são todos riscos de cadeia de suprimentos que colocam código malicioso ou vulnerável dentro do seu limite de confiança.

Configuration drift e erro humano. Muitos dos incidentes mais danosos remontam não a um exploit inédito, mas a uma configuração incorreta: um dashboard exposto sem autenticação, um secret commitado em um repositório, uma role vinculada de forma ampla demais. Direcionalmente, configurações incorretas e exposição de credenciais respondem por grande parte dos incidentes reais no Kubernetes, e é por isso que boa parte das boas práticas trata de padrões e guardrails, e não de defesas exóticas.

Também ajuda pensar em termos das fases pelas quais um atacante passa: acesso inicial (uma aplicação vulnerável, uma credencial vazada, um endpoint exposto), execução e persistência dentro de um workload, escalada de privilégios do container para o node e para o cluster e, por fim, impacto, exfiltrar dados, minerar criptomoedas nos seus nodes ou adulterar workloads. Cada um dos pilares mais adiante neste guia interrompe uma ou mais dessas fases. RBAC de menor privilégio e pods endurecidos elevam o custo do primeiro ponto de apoio e da escalada; as network policies estrangulam a movimentação lateral; a proteção de secrets limita o que um workload comprometido consegue alcançar; e os controles de cadeia de suprimentos reduzem a chance de o atacante ter sido convidado a entrar por meio de uma imagem que você construiu.

Mapear isso para um modelo de ameaças dá as prioridades que orientam o restante deste guia: controlar o acesso de forma rigorosa, restringir o que os workloads podem fazer, segmentar a rede, proteger os secrets e confiar apenas nas imagens e dependências que você verificou.

Os pilares centrais da segurança no Kubernetes

As áreas de prática abaixo são o coração de um programa de segurança no Kubernetes. Cada uma é um assunto profundo por si só, então cada uma tem um guia satélite dedicado. Use esta seção como o mapa e siga os links quando estiver pronto para implementar.

RBAC e controle de acesso

O controle de acesso baseado em papéis (RBAC) rege quem e o que pode executar quais ações contra o API server. Esta é sua primeira e mais importante linha de defesa e também uma das mais fáceis de errar: bindings de cluster-admin distribuídos por conveniência, service accounts com muito mais acesso do que seus workloads precisam e nenhuma revisão periódica. O objetivo é o menor privilégio, roles com escopo definido vinculadas a subjects específicos em namespaces específicos e um tratamento disciplinado dos tokens de service account. Veja o aprofundamento em RBAC e controle de acesso no Kubernetes.

Segurança de pods

Os pods podem ser configurados para entregar tudo de mão beijada, rodando como root, montando o filesystem do host, compartilhando namespaces do host ou solicitando modo privilegiado. O endurecimento em nível de pod usa securityContext e Pod Security Admission (o sucessor embutido da removida PodSecurityPolicy) para impor os padrões baseline e restricted, de modo que um container comprometido não consiga escalar facilmente para o node. Todos os detalhes no guia de segurança de pods no Kubernetes.

Network policies

Por padrão, a rede do cluster é plana: todo pod pode alcançar todo outro pod. As network policies permitem definir quais workloads podem se comunicar, implementando microssegmentação e uma postura de default-deny que limita drasticamente a movimentação lateral após um comprometimento. Aprenda a projetá-las e implantá-las no guia de network policies no Kubernetes.

Gestão de secrets

Os Secrets do Kubernetes são, por padrão, apenas codificados em base64 no etcd, não criptografados, e podem ser lidos com facilidade por qualquer pessoa com o acesso adequado à API. Protegê-los significa habilitar a criptografia em repouso, restringir o acesso com RBAC, evitar secrets em manifests e variáveis de ambiente sempre que possível e, muitas vezes, integrar um gerenciador de secrets externo. O guia de gestão de secrets no Kubernetes cobre os padrões.

Segurança de imagens e da cadeia de suprimentos

Tudo o que você executa começa como uma imagem construída a partir de uma base e de um conjunto de dependências. Minimizar as imagens base, escanear vulnerabilidades conhecidas, fixar e verificar a proveniência e gerar uma software bill of materials, tudo isso reduz a chance de você implantar algo explorável. É aqui que a segurança de containers encontra a análise de composição de software. Veja segurança de imagens e da cadeia de suprimentos no Kubernetes.

Admission control e segurança em runtime

Duas camadas transversais amarram os pilares. O admission control, por meio de admission webhooks de validação e mutação e de policy engines, permite impor regras no momento do deploy: rejeitar um pod que roda como root, exigir imagens assinadas, bloquear um workload sem limites de recursos. É assim que você transforma boas práticas em guardrails que não podem ser contornados por um kubectl apply apressado.

A segurança em runtime pressupõe que algum risco sempre vai passar e observa o cluster enquanto ele roda, detectando atividade de processos anômala, conexões de rede inesperadas ou tentativas de container escape, e dando a você o sinal para responder. O admission control mantém as configurações ruins de fora; a segurança em runtime captura o que entra mesmo assim. Junto com os pilares acima, elas formam a defesa em profundidade.

Segurança no Kubernetes ao longo do SDLC: shift-left

A mudança mais eficaz que a maioria das equipes pode fazer é mover a segurança para mais cedo, aplicar o shift-left, para que os problemas sejam capturados quando são baratos de corrigir, e não depois de já estarem rodando em produção. O Kubernetes torna isso prático porque grande parte do que você implanta é declarada como código.

Escreva e escaneie manifests e IaC. Seus manifests Kubernetes, Helm charts e templates de infraestrutura como código são onde nascem as configurações incorretas. Escaneá-los no repositório e nos pull requests captura o container-rodando-como-root, a network policy ausente ou a role ampla demais antes que sejam aplicados. Essa é a mesma disciplina descrita em nossa análise mais ampla sobre o que é application security, aplicada à infraestrutura.

Escaneie imagens no CI. Os pipelines de build são o lugar certo para escanear imagens de container em busca de vulnerabilidades conhecidas e para checar dependências com análise de composição de software. Falhar um build por uma vulnerabilidade crítica e corrigível é muito mais barato do que aplicar patch em uma frota de pods em execução. Fixe imagens base, verifique a proveniência e mantenha as imagens mínimas.

Imponha no admission. Use o admission control como o portão entre "declarado" e "em execução". Políticas que exigem imagens assinadas, proíbem pods privilegiados ou obrigam limites de recursos garantem que os padrões que vocês acordaram sejam de fato cumpridos no momento do deploy.

Monitore em runtime. Por fim, observe o que está realmente acontecendo no cluster, tanto em busca de ameaças quanto de desvios da baseline segura que você estabeleceu antes. Um workload que de repente abre um shell, tenta alcançar o endpoint de metadados da nuvem ou abre uma conexão que nunca fez antes merece investigação, e os sinais de runtime também são como você descobre que um controle que você achava estar no lugar parou de funcionar silenciosamente.

O retorno dessa ordenação é econômico. Uma configuração incorreta capturada em um pull request custa alguns minutos de um desenvolvedor; o mesmo problema capturado em um cluster de produção em execução pode significar um incidente, um rollout e uma auditoria. Aplicar o shift-left não significa fazer menos segurança depois, significa que as etapas posteriores têm muito menos a capturar. Igualmente importante, um feedback entregue nas ferramentas que os desenvolvedores já usam, o repositório, o pull request, o pipeline de CI, é um feedback sobre o qual as equipes vão agir, ao passo que um relatório que chega a um console separado dias depois tende a ser ignorado.

Essa visão de ciclo de vida é a essência de sair do DevOps para o DevSecOps: a segurança se torna uma propriedade do pipeline, de responsabilidade das equipes que constroem e executam o software, em vez de um portão parafusado no final.

Melhores práticas de segurança no Kubernetes

As práticas abaixo destilam os pilares em um checklist funcional. Trate-o como ponto de partida e siga os guias satélite para se aprofundar. Uma lista mais completa e priorizada está no guia dedicado de melhores práticas de segurança no Kubernetes.

• Aplique o menor privilégio em toda parte: roles de RBAC com escopo definido, permissões mínimas de service account e nenhum binding de cluster-admin padrão.
• Blinde o control plane: restrinja e autentique o acesso ao API server e ao etcd, habilite o audit logging e criptografe o etcd em repouso.
• Endureça os pods com securityContext e Pod Security Admission: sem root, sem modo privilegiado, filesystems raiz somente leitura onde for viável e capabilities do Linux descartadas.
• Segmente a rede com network policies de default-deny, abrindo apenas as conexões de que os workloads genuinamente precisam.
• Proteja os secrets: habilite a criptografia em repouso, restrinja o acesso, mantenha os secrets fora das imagens e do controle de versão e considere um gerenciador de secrets externo.
• Proteja a cadeia de suprimentos: use imagens base mínimas e confiáveis, escaneie imagens e dependências, verifique a proveniência e mantenha uma software bill of materials.
• Imponha padrões com admission control para que os guardrails não possam ser pulados sob a pressão de prazos.
• Monitore em runtime e mantenha tudo, Kubernetes, nodes e imagens, com patch e atualizado.
• Torne isso contínuo: escaneie manifests, IaC e imagens a cada mudança, em vez de em auditorias periódicas.

Como a Rainforest ajuda

Grande parte da segurança no Kubernetes se resume a confiar no que você implanta e saber onde está o risco, entre imagens, código de infraestrutura e dependências. A Rainforest é uma plataforma de teste de segurança de aplicações que cobre exatamente essas superfícies, para que as verificações descritas ao longo deste guia aconteçam automaticamente como parte de como suas equipes constroem.

• A segurança de imagens de container escaneia as imagens que você entrega em busca de vulnerabilidades conhecidas e configurações inseguras, para que uma falha crítica em uma imagem base seja capturada no CI, e não em produção. Saiba mais na página de segurança de containers.
• A análise de infraestrutura como código examina seus manifests Kubernetes, Helm charts e templates de IaC em busca de configurações incorretas, a role ampla demais, a network policy ausente, o pod privilegiado, antes que sejam aplicados. Veja análise de IaC.
• A análise de composição de software identifica dependências vulneráveis e arriscadas no seu código e nas suas imagens, tratando a camada de cadeia de suprimentos do modelo dos 4C's. Veja análise de composição de software.
• Os achados unificados trazem os resultados de imagens, IaC e dependências para uma única visão priorizada, para que suas equipes corrijam as causas-raiz de uma vez, em vez de triar alertas duplicados entre ferramentas desconectadas. Explore a plataforma de teste de segurança de aplicações completa.

Se você quiser ver como isso funciona nos seus próprios clusters e pipelines, agende uma demonstração e vamos percorrer tudo com a sua stack.