Organizando o Gerenciamento de Segredos no Kubernetes com um Cofre de Segredos

Com o aumento da complexidade das infraestruturas, gerenciar segredos se torna um desafio cada vez maior. Em ambientes de contêineres como o Kubernetes, onde cada contêiner pode necessitar de acesso a recursos de informação específicos, a tarefa se intensifica. Inserir segredos diretamente no código ou deixá-los expostos em contêineres representa um risco significativo de comprometimento. Este artigo explora as melhores práticas para organizar o gerenciamento de segredos no Kubernetes, utilizando um sistema dedicado de gerenciamento de segredos e as ferramentas nativas disponíveis.

Incidentes de segurança relacionados ao manuseio inadequado de segredos são recorrentes. Um exemplo notório foi o caso da Uber em 2016, onde um access key encontrado em um repositório privado permitiu o acesso aos dados de milhões de usuários e motoristas. Em 2018, a Tesla enfrentou um incidente de criptojacking em seu cluster Kubernetes devido a uma console mal configurada, que expôs credenciais de nuvem. Para mitigar tais riscos, a Orion soft emprega o StarVault, uma ferramenta de gerenciamento de segredos integrada à sua plataforma de contêineres Nova. O StarVault é implantado como um conjunto de serviços em máquinas virtuais fora do cluster Kubernetes, garantindo que o cofre de segredos não seja afetado pelo estado dos Pods ou namespaces. Sua alta disponibilidade (HA) e ciclo de vida são gerenciados pela plataforma, com um PKI integrado para emissão de certificados e armazenamento seguro dos segredos dos componentes da Nova Container Platform.

Para garantir uma autenticação unificada, o StarVault se integra a um IdP corporativo, atuando como um provedor ou broker OIDC para os serviços da plataforma. Isso centraliza a normalização de informações de identidade, claims, scopes e grupos. Os serviços, por sua vez, são configurados como clientes OIDC do StarVault, utilizando os dados recebidos para decisões de autorização. Nessa arquitetura, os segredos não são criados como Kubernetes Secrets nem armazenados no etcd. Em vez disso, as aplicações os obtêm diretamente do StarVault através de um volume CSI ou de um injector. Essa abordagem minimiza a superfície de ataque, embora a proteção do próprio StarVault, dos tokens ServiceAccount, dos nós Kubernetes e da aplicação após a leitura do segredo permaneça crucial.

Dentro da plataforma de contêineres, dois tipos de injetores são utilizados: Vault CSI e Banzai Webhook. O Vault CSI monta segredos como um volume tmpfs, ideal para aplicações que leem segredos de arquivos e não necessitam de variáveis de ambiente. A vantagem é que o segredo permanece no StarVault, sendo acessado via tmpfs. A rotação de segredos é suportada pelo driver CSI, mas a aplicação deve ser capaz de reler o arquivo, ou um reinício/redeploy será necessário. A autenticação geralmente ocorre via Kubernetes/JWT com o token ServiceAccount do Pod. No entanto, a entrega de segredos como arquivos limita a flexibilidade, e a injeção via variáveis de ambiente requer sincronização adicional com Kubernetes Secrets, retornando o segredo ao etcd. O CSI não é recomendado para objetos grandes ou segredos frequentemente atualizados.

O Banzai Webhook é uma alternativa quando o Vault CSI não é adequado. Este webhook mutante modifica o PodSpec para iniciar a aplicação através de um wrapper vault-env. Durante a inicialização, vault-env obtém os valores do StarVault e os injeta no ambiente do processo. Este não é um padrão sidecar clássico, pois os segredos são injetados no início do processo, não por um agente Vault sidecar persistente. As vantagens incluem universalidade, permitindo a integração de qualquer aplicação sem alteração de código, suporte a autenticação Kubernetes e JWT, e integração simples via anotações. Contudo, em implantações em massa, pode haver um aumento na latência durante a fase de admission. Modificações no PodSpec ocorrem na criação ou alteração do Pod; a indisponibilidade do webhook durante essa fase pode impactar o resultado, dependendo da failurePolicy e do timeout. A indisponibilidade do StarVault na inicialização do contêiner pode levar a erros de aplicação. Atualizações de segredos não refletem automaticamente em variáveis de ambiente de processos em execução, exigindo reinício ou mecanismos de atualização.

O terceiro componente essencial é o PKI (Public Key Infrastructure). Em vez de uma solução separada, o StarVault é utilizado para gerenciar o PKI. A configuração recomendada é um Root CA offline e um Intermediate CA online dentro do StarVault. A alocação do Root CA corporativo no StarVault é uma exceção que requer proteção rigorosa das chaves, procedimentos de unseal, auditoria, backup e DR. Essa integração PKI oferece benefícios como o gerenciamento declarativo do ciclo de vida de certificados pelo cert-manager no Kubernetes, enquanto o StarVault atua como centro de emissão, armazenando roles, políticas e auditoria. A operação se beneficia de menos componentes e um único contorno operacional. As desvantagens incluem o crescimento de metadados PKI e CRLs com um grande número de certificados, exigindo planejamento de TTL, CRL/OCSP e armazenamento. O aumento de requisições pode demandar mais recursos de CPU para o Vault. A interface do usuário (UI) do StarVault é limitada para certificados, com a maioria das operações realizadas via API. A co-localização do PKI e dos segredos em um mesmo contorno operacional introduz um ponto de falha parcial, exigindo planejamento cuidadoso de HA, backup, recuperação, auditoria e DR.

Em infraestruturas dinâmicas com múltiplos clusters, o gerenciamento de segredos se torna mais complexo. A plataforma HyperDrive, baseada em GitOps, gerencia o ciclo de vida da infraestrutura, orquestrando componentes como Nova Container Platform, Kubernetes, StarVault e GitLab. O HyperDrive não substitui essas ferramentas, mas as integra em um processo unificado, desde a criação de clusters até a entrega de configurações e segredos. Dentro do HyperDrive, os segredos são incorporados ao ciclo de vida da infraestrutura, eliminando a necessidade de transferência manual de valores entre instâncias do Vault, criação de políticas em cada cluster e o risco de inclusão de segredos em manifestos GitOps.

O StarVault opera em um modelo "1+N" com o HyperDrive. Um StarVault principal no contorno de gerenciamento do HyperDrive serve como cofre central de segredos da plataforma. Cada cluster Nova possui seu próprio StarVault local, que pode ser compartilhado ou dedicado a uma arquitetura específica. O StarVault principal é a fonte da verdade para os segredos gerenciados pelo HyperDrive. Os StarVaults locais nos clusters Nova são usados para acesso de aplicações em tempo de execução, recebendo apenas os segredos, políticas e configurações de acesso necessários para aquele cluster. Essa abordagem evita que todas as requisições de aplicações cheguem ao contorno central do HyperDrive, mantendo o gerenciamento centralizado. Os StarVaults locais não são cópias completas do cofre central; apenas caminhos KV v2 selecionados são sincronizados, limitando o impacto de erros ou comprometimentos. O contorno de gerenciamento do HyperDrive é responsável pelo ciclo de vida dos segredos, armazenando metadados como identificador, caminho, tipo, proprietário e parâmetros de sincronização, mas não os valores dos segredos em si, que permanecem no StarVault KV v2.

O StarVault-wrapper atua como a camada de execução para interagir com as instâncias do Vault. Ele registra clusters e StarVaults locais, configura caminhos de sincronização, copia segredos KV v2 do StarVault principal para os locais e cria políticas de acesso e roles de autenticação Kubernetes para aplicações. O ciclo de vida de um segredo envolve o registro do valor no StarVault principal pelo serviço de gerenciamento do HyperDrive, seguido pela criação de uma política de sincronização se o segredo for necessário em um cluster específico. O StarVault-wrapper então sincroniza o segredo para o StarVault local. Para acesso de aplicações, o wrapper cria políticas de acesso Vault e roles Kubernetes mínimas necessárias, vinculadas a namespaces e ServiceAccounts específicos, garantindo que as aplicações acessem apenas os caminhos necessários. Os manifestos GitOps contêm referências e parâmetros de acesso, mas não os valores dos segredos. Essa abordagem facilita a criação e configuração de novos clusters, a aplicação de políticas de sincronização e a automação de acessos, liberando as equipes da gestão manual de segredos e da verificação de vazamentos em GitOps. É importante notar que a sincronização não substitui o backup; o StarVault-wrapper apenas sincroniza caminhos KV v2 explicitamente selecionados. O StarVault principal permanece a fonte da verdade, e as alterações locais são restritas por políticas de acesso, permitindo a recuperação previsível das instâncias locais do StarVault.

Em resumo, o HyperDrive gerencia um modelo de entrega de segredos, com o StarVault principal armazenando os valores, os StarVaults locais servindo as aplicações nos clusters Nova, e o StarVault-wrapper conectando esses níveis e garantindo a configuração correta dos acessos. Um sistema de gerenciamento de segredos robusto é fundamental para resolver desafios de segurança e acesso em instalações de diferentes escalas e distribuições geográficas. A experiência com StarVault e dúvidas sobre os componentes são bem-vindas nos comentários.