Segurança do Kubernetes: RBAC, Políticas de Rede e Segurança de Pods

O Kubernetes orquestra cargas de trabalho conteinerizadas em grande escala, mas sua complexidade cria uma ampla superfície de ataque. Os principais componentes que devem ser protegidos incluem: o Servidor da API (o plano de controle central — seu comprometimento fornece controle de todo o cluster), o etcd (o banco de dados do estado do cluster — armazena segredos em base64 e deve ser criptografado em repouso), o kubelet (agente do nó — uma API do kubelet sem autenticação permite a execução arbitrária de pods), o tempo de execução de contêineres (Docker/containerd) e a rede que conecta todos os pods. Os candidatos à Security+ devem entender que configurações incorretas do Kubernetes estão entre as descobertas mais comuns de segurança na nuvem.

O RBAC (Controle de Acesso Baseado em Funções) do Kubernetes controla quais usuários, contas de serviço e processos podem executar quais ações em quais recursos da API. O modelo tem quatro objetos: Role (permissões no escopo de um namespace), ClusterRole (permissões em todo o cluster), RoleBinding (concede uma Role a um sujeito dentro de um namespace) e ClusterRoleBinding (concede uma ClusterRole a um sujeito em todo o cluster). Cada comando kubectl é convertido em uma chamada à API, que é verificada com base nas regras de RBAC. Se o RBAC não estiver configurado, qualquer usuário autenticado (ou conta de serviço) poderá ter acesso administrativo.

Todo pod no Kubernetes é executado sob uma conta de serviço — uma identidade usada para autenticação na API. Por padrão, os pods usam a conta de serviço default em seu namespace, que pode ter permissões amplas. O princípio do privilégio mínimo exige a criação de contas de serviço dedicadas para cada aplicativo, com apenas as permissões necessárias. Além disso, definir automountServiceAccountToken: false nos pods que não precisam de acesso à API impede que o token da conta de serviço seja montado no sistema de arquivos do pod, onde um aplicativo comprometido poderia usá-lo para fazer chamadas à API.

Por padrão, no Kubernetes, todos os pods podem se comunicar com todos os outros pods em qualquer namespace. Um pod comprometido pode tentar imediatamente alcançar bancos de dados, APIs internas e outros microsserviços. Os recursos NetworkPolicy do Kubernetes definem regras que restringem o tráfego entre pods com base em rótulos, namespaces e portas. A abordagem recomendada é uma política de rede de “negação padrão de tudo” em cada namespace, seguida de regras explícitas de permissão para os caminhos de comunicação necessários. Observe que a NetworkPolicy exige um plugin CNI que ofereça suporte a ela (Calico, Cilium, Weave) — o Kubernetes básico ignora a NetworkPolicy sem um CNI compatível.

Os Pod Security Standards (PSS), introduzidos no Kubernetes 1.23 e estabilizados na versão 1.25, substituem o Pod Security Policy (PSP), obsoleto, por três perfis integrados aplicados no nível do namespace: Privileged (sem restrições, para componentes do sistema), Baseline (impede escalações de privilégio conhecidas, como contêineres privilegiados e acesso à rede do host) e Restricted (reforçado, exige usuários não root, remove todas as capacidades e impõe sistemas de arquivos raiz somente leitura). Os namespaces recebem rótulos para impor um nível de política, e os pods que o violam são rejeitados na admissão.

Os Secrets do Kubernetes armazenam dados confidenciais, como senhas, tokens e certificados TLS. Por padrão, os Secrets são armazenados no etcd como valores codificados em base64 — não criptografados. Qualquer pessoa que possa ler o etcd ou tenha permissões suficientes de RBAC pode decodificá-los facilmente. As práticas recomendadas incluem: habilitar a criptografia em repouso do etcd usando AES-GCM com uma chave armazenada em um KMS (AWS KMS, GCP KMS); integrar-se a um gerenciador externo de segredos, como o HashiCorp Vault ou o AWS Secrets Manager, por meio do Secrets Store CSI Driver; e restringir o acesso aos Secrets via RBAC, para que apenas as contas de serviço que precisam deles possam lê-los.

Os controladores de admissão são plugins no servidor da API do Kubernetes que interceptam solicitações à API após a autenticação e a autorização, mas antes da persistência do objeto, permitindo validar, modificar ou rejeitar solicitações. Entre os controladores de admissão relevantes para a segurança estão: PodSecurity (impõe os Padrões de Segurança de Pods), ImagePolicyWebhook (permite a verificação externa de assinaturas de imagens), AlwaysPullImages (força a extração de imagens novas para impedir o uso de imagens maliciosas armazenadas localmente) e OPA/Gatekeeper (Open Policy Agent — a opção mais flexível, que permite políticas personalizadas expressas na linguagem Rego para impor qualquer regra de segurança organizacional).

O reforço de segurança dos componentes do plano de controle do Kubernetes é crítico: o servidor da API deve usar --anonymous-auth=false para desabilitar o acesso sem autenticação, ter --audit-log-path configurado para capturar toda a atividade da API e usar TLS em todas as conexões. O kubelet deve usar --authorization-mode=Webhook (não AlwaysAllow) e ter a autenticação anônima desabilitada. O etcd deve usar criptografia TLS entre pares e para clientes, ter o acesso à rede restrito (ser acessível apenas pelo servidor da API) e manter os dados criptografados em repouso. O CIS Kubernetes Benchmark fornece uma lista de verificação abrangente para todas as configurações dos componentes.

Os namespaces do Kubernetes fornecem separação lógica de recursos, mas, por si só, não constituem uma fronteira de segurança forte — eles oferecem principalmente isolamento organizacional. Para um isolamento real de multilocação (por exemplo, cargas de trabalho de clientes diferentes), são necessários controles adicionais: políticas de rede para bloquear o tráfego entre namespaces, cotas de recursos para impedir ataques de negação de serviço causados por vizinhos ruidosos, conjuntos de nós separados para locatários fortemente isolados ou clusters dedicados por locatário. Muitas organizações usam Hierarchical Namespaces ou soluções comerciais como o vCluster para obter uma multilocação mais forte dentro de um único cluster.

O registro de auditoria do Kubernetes registra cada solicitação à API: quem a fez, de onde veio, qual ação foi solicitada e qual recurso foi visado. Os registros de auditoria são essenciais para investigações forenses após um incidente de segurança e para detectar comportamentos anômalos, como associações de funções incomuns, acesso a segredos ou comandos exec em pods de produção. Os registros de auditoria devem ser transmitidos para um SIEM centralizado. O Falco fornece monitoramento do comportamento dos contêineres em tempo de execução, enquanto os serviços Kubernetes gerenciados pela nuvem (EKS, GKE, AKS) oferecem integração nativa dos registros de auditoria com suas respectivas plataformas de registro.

A segurança da cadeia de fornecimento do Kubernetes garante que somente imagens confiáveis e verificadas cheguem à produção. As recomendações da CNCF sobre segurança da cadeia de fornecimento incluem: verificar as assinaturas das imagens com o Cosign antes da implantação (imposto por controladores de admissão), gerar e verificar SBOMs (listas de materiais de software) para todas as imagens de contêiner, a fim de rastrear a procedência dos componentes, fixar as imagens a resumos criptográficos (myimage@sha256:abc123) em vez de etiquetas mutáveis e verificar todos os gráficos Helm de terceiros quanto a configurações incorretas e vulnerabilidades antes da implantação.

Avalie sua compreensão dos conceitos do CompTIA Security+ (SY0-701) apresentados nesta lição.

Nesta lição, você aprendeu que: o RBAC do Kubernetes controla o acesso à API por meio de funções, ClusterRoles e associações — sempre aplique o princípio do menor privilégio às contas de serviço; as configurações NetworkPolicy de negação padrão impedem movimentos laterais entre pods e namespaces; e os Padrões de Segurança de Pods impõem o fortalecimento dos contêineres no nível do namespace, bloqueando contêineres privilegiados, acesso à rede do host e execução como root. A seguir, exploraremos a segurança sem servidor e as superfícies de ataque no nível das funções.