External Secrets

https://external-secrets.io

No complexo ecossistema do Kubernetes, a gestão de informações sensíveis, como senhas, chaves de API e tokens de autenticação, representa um desafio crítico para a segurança e a operacionalidade das aplicações.

O External Secrets Operator (ESO) é solução robusta, consolidada na CNCF, ideal para sincronizar segredos de fontes externas diretamente para dentro do cluster Kubernetes.

É um operador do Kubernetes que estende a API do Kubernetes com Recursos Customizados (Custom Resource Definitions - CRDs). Sua principal função é ler informações de provedores de segredos externos, como AWS Secrets Manager, HashiCorp Vault, Google Secret Manager e Azure Key Vault, e injetá-las automaticamente como Secrets nativos do Kubernetes.

Em sua essência, o ESO atua como uma ponte segura. As equipes de desenvolvimento e operações podem manter seus segredos centralizados e gerenciados em um local seguro e auditável, enquanto as aplicações dentro do Kubernetes podem consumir esses segredos da maneira padrão, através de variáveis de ambiente ou volumes, sem a necessidade de modificações complexas.

A arquitetura do External Secrets se baseia em dois CRDs principais:

• SecretStore ou ClusterSecretStore: Define como se conectar e autenticar em um provediente de segredos externo. A versão ClusterSecretStore permite que a configuração seja acessível por todos os namespaces do cluster, enquanto a SecretStore é limitada a um único namespace.

• ExternalSecret: Descreve qual segredo deve ser buscado no provedor externo e como ele deve ser criado ou atualizado no Kubernetes. Este recurso referencia um SecretStore para obter as credenciais de acesso necessárias.

Vantagens

• Centralização e Gestão Externa: Permite que os segredos sejam gerenciados por sistemas especializados, que oferecem recursos avançados de auditoria, rotação automática e políticas de acesso granulares.

• Segurança Aprimorada (GitOps): Ao evitar que os valores dos segredos sejam armazenados diretamente nos manifestos YAML do Kubernetes, o External Secrets é um aliado fundamental para práticas de GitOps. Os repositórios Git contêm apenas a referência ao segredo externo, não o seu valor, reduzindo drasticamente o risco de exposição.

• Sincronização Automática: O operador monitora continuamente o provedor de segredos externo. Qualquer alteração nos segredos é automaticamente sincronizada com os Secrets correspondentes no Kubernetes, garantindo que as aplicações sempre tenham as credenciais mais recentes.

• Compatibilidade com Aplicações: Como o resultado final é um Secret nativo do Kubernetes, as aplicações não precisam de nenhuma lógica customizada para interagir com o provedor de segredos. Elas consomem os segredos da forma como sempre fizeram.

• Amplo Suporte a Provedores: A ferramenta é compatível com uma vasta gama de provedores de segredos, tanto de nuvens públicas quanto soluções on-premises, oferecendo flexibilidade para diferentes arquiteturas.

• Comunidade Ativa e Projeto de Código Aberto: Sendo um projeto da CNCF (Cloud Native Computing Foundation), o External Secrets possui uma comunidade vibrante e um desenvolvimento ativo, o que garante bom suporte, atualizações constantes e uma base de usuários sólida.

Desvantagens

Apesar de suas inúmeras vantagens, é importante considerar alguns pontos antes de adotar o External Secrets:

• Complexidade de Configuração Inicial: Envolve a criação dos SecretStores e a definição das permissões corretas tanto no cluster quanto nos provedores externos, pode ser complexa para equipes menos experientes com o Kubernetes.

• Ainda Utiliza Secrets Nativos: Para aplicações que requerem o mais alto nível de segurança, o fato de o External Secrets materializar o segredo em um Secret nativo do Kubernetes (que por padrão é apenas codificado em Base64 no etcd) pode ser uma desvantagem. Embora o etcd possa ser criptografado, algumas políticas de segurança podem proibir o armazenamento de segredos no cluster. Pode ser considerado uma vantagem ou desvantagem o fato do segredo se materializar no como objeto no cluster .Se fôssemos injetar um segredo diretamente vindo do vault ou qualquer outro provider durante a inicialização de um pod e essa conexão falhar o pod não inicializaria, mas em um secret que já esta no kubernetes eliminamos mais uma depedência.

• Dependência de um Componente Adicional: Adiciona mais um controller no cluster que precisa ser monitorado, mantido e atualizado.

• Performance em Larga Escala: Em clusters muito grandes com um número massivo de segredos sendo sincronizados, a performance do operador pode se tornar um ponto de atenção, consumindo recursos e gerando um volume considerável de logs.

• Tempo de Sync: Existe uma latência entre o external secret entender que um segredo mudou.

Por que se Tornou a Ferramenta Mais Usada?

A ascensão do External Secrets ao posto de ferramenta mais utilizada para a gestão de segredos no Kubernetes pode ser atribuída a uma combinação de fatores:

• Solução para um Problema Universal: A gestão de segredos é uma dor universal em ambientes de contêineres, e o External Secrets oferece uma solução elegante e eficaz que se integra perfeitamente ao ecossistema do Kubernetes.

• Abordagem "GitOps-Friendly": Com a popularização do GitOps como padrão para a entrega contínua, a capacidade de manter os segredos fora dos repositórios Git se tornou um requisito fundamental.

• Equilíbrio entre Segurança e Usabilidade: A ferramenta encontra um excelente equilíbrio ao permitir que os segredos sejam gerenciados em cofres externos seguros, sem impor uma grande sobrecarga de desenvolvimento às equipes de aplicação, que podem continuar a consumir os segredos de maneira familiar.

External Secrets vs. Sealed Secrets Vs. GitOps

Enquanto o External Secrets Operator (ESO) se consolidou como uma das soluções mais populares e robustas, o Sealed Secrets oferece uma abordagem distinta e mais simples, que pode ser a ideal para determinados cenários. A escolha entre eles depende fundamentalmente da arquitetura, da escala da sua operação e do seu fluxo de trabalho de GitOps.

External Secrets: Sua principal vantagem reside na centralização e no gerenciamento unificado dos segredos, atuando como um HUB que facilita a auditoria, rotação de chaves, etc, mas que trás consigo as dependências de serviços externo e uma complexidade extra como já vimos antes.

Sealed Secrets: Tem um foco completo no GitOps, mas vem com uma abordagem completamente diferente. Em vez de se conectar a um cofre externo, ele permite que você criptografe segredos de forma segura para que possam ser armazenados diretamente em um repositório Git.

Como Funciona o Sealed Secrets

Um controlador é instalado no cluster Kubernetes, que gera um par de chaves (pública e privada).

A chave pública é utilizada para criptografar (selar) seus arquivos de manifesto de Secret do Kubernetes. O resultado é um novo objeto SealedSecret, que é seguro para ser comitado no Git.

O controlador no cluster é o único que possui a chave privada e, portanto, o único capaz de descriptografar (desvendar) o SealedSecret e criar o Secret nativo no cluster.

Principais Vantagens do Sealed Secrets

• Fluxo de Trabalho de GitOps Puro: Permite que tudo, incluindo os segredos, seja versionado e gerenciado através do Git. Isso simplifica o processo de implantação e garante um estado declarativo completo da sua infraestrutura.

• Autocontido: Não há dependências de serviços externos para o gerenciamento dos segredos em tempo de execução. Tudo o que é necessário está no cluster e no repositório Git.

• Simplicidade: É relativamente mais simples de configurar e usar em comparação com o External Secrets, especialmente para equipes menores e ambientes menos complexos.

• Segurança no Repositório: O segredo original nunca é exposto no repositório Git, apenas sua versão criptografada.

Desvantagens do Sealed Secrets

• Gerenciamento Descentralizado: Cada cluster possui seu próprio par de chaves, o que pode dificultar o gerenciamento de segredos em uma vários clusters.

• Rotação de Chaves: A rotação da chave de criptografia do Sealed Secrets exige a recriptografia de todos os segredos existentes, o que pode ser um processo manual e propenso a erros.

• Menos Recursos Avançados: Não oferece os mesmos recursos de auditoria e gerenciamento de ciclo de vida de segredos que os provedores de segredos dedicados.

É importante lembrar que limitações podem ser contornadas e processos manuais automatizados mas não é uma feature que já vem com a ferramenta.

Característica	External Secrets Operator	Sealed Secrets
Fonte da Verdade	Provedor de segredos externo (Vault, AWS SM, etc.)	Repositório Git
Fluxo de Trabalho	Sincronização com fonte externa	Criptografia e commit no Git (GitOps)
Dependências	Provedor de segredos externo	Autocontido no cluster
Escalabilidade	Alta, ideal para múltiplos clusters	Menos escalável para múltiplos clusters
Rotação de Segredos	Gerenciada pelo provedor externo, sincronização automática	Manual, requer recriptografia
Complexidade	Moderada a alta	Baixa a moderada
Caso de Uso Ideal	Ambientes corporativos, múltiplos clusters, necessidade de auditoria centralizada.	Projetos que seguem GitOps à risca, ambientes mais simples, armazenamento de toda a configuração no Git.

---

Para a maioria das organizações que já utilizam um provedor de segredos centralizado ou que operam em uma escala que exige gerenciamento e auditoria robustos, o External Secrets é, de fato, a escolha mais completa e segura.

No entanto, o Sealed Secrets tem um valor imenso e não deve ser descartado. É uma excelente opção para:

• Equipes que adotam o GitOps como filosofia principal e desejam ter uma única fonte de verdade declarativa em seus repositórios.

• Cenários mais simples, com um número limitado de clusters, onde a sobrecarga de gerenciar um cofre de segredos externo não se justifica.

• Aplicações de código aberto ou projetos onde a simplicidade e a ausência de dependências externas são prioritárias.