# Gestão de Secrets no Kubernetes em 2026: External Secrets, Vault e Perguntas de Entrevista > Guia completo sobre gestão de secrets no Kubernetes com External Secrets Operator e HashiCorp Vault. Padrões de rotação automática, integração multi-cloud e perguntas de entrevista DevOps. - Published: 2026-09-02 - Updated: 2026-09-02 - Author: Anthony Fillion-Maillet - Tags: kubernetes, secrets, vault, external-secrets, security, devops - Reading time: 12 min --- A gestão de secrets no Kubernetes permanece como um dos desafios de segurança mais críticos na orquestração de containers. Os Secrets nativos do Kubernetes armazenam dados sensíveis como valores codificados em base64, o que não fornece criptografia em repouso por padrão e cria riscos de segurança frequentemente explorados durante processos de contratação DevOps. > **Resposta Rápida para Entrevista** > > Quando perguntado sobre segurança de secrets no Kubernetes: os Secrets nativos são codificados em base64, não criptografados. Ambientes de produção requerem gerenciadores de secrets externos como HashiCorp Vault ou AWS Secrets Manager, sincronizados via External Secrets Operator (ESO). Essa separação garante que os secrets nunca existam em repositórios Git. ## Por Que os Secrets Nativos do Kubernetes São Insuficientes O recurso Secret integrado armazena dados no etcd com codificação base64. Essa codificação é reversível com um simples comando: ```bash # decoding-secret.sh # Decodificar qualquer valor de secret do Kubernetes instantaneamente kubectl get secret db-credentials -o jsonpath='{.data.password}' | base64 -d ``` Base64 não é criptografia. Qualquer pessoa com acesso ao cluster pode ler os valores dos secrets. A [documentação do Kubernetes](https://kubernetes.io/docs/concepts/configuration/secret/) alerta explicitamente que os Secrets "não são criptografados por padrão" e recomenda habilitar a criptografia em repouso. Três limitações principais afetam deploys em produção: 1. **Sem trilha de auditoria**: Os Secrets nativos não registram quem acessou qual valor e quando 2. **Sem mecanismo de rotação**: Alterar um secret requer intervenção manual e reinício dos pods 3. **Incompatibilidade com GitOps**: Armazenar secrets criptografados no Git ainda expõe o problema de gerenciamento de chaves de criptografia ## Arquitetura do External Secrets Operator O External Secrets Operator (ESO) conecta o Kubernetes com sistemas externos de gestão de secrets. Lançado como projeto CNCF Sandbox em 2023 e alcançando a versão 0.10 em 2026, o ESO suporta AWS Secrets Manager, HashiCorp Vault, Google Secret Manager, Azure Key Vault e mais 15 backends. A arquitetura envolve três recursos customizados: ```yaml # secret-store.yaml # ClusterSecretStore define a conexão com o Vault apiVersion: external-secrets.io/v1beta1 kind: ClusterSecretStore metadata: name: vault-backend spec: provider: vault: server: "https://vault.internal:8200" path: "secret" version: "v2" auth: kubernetes: mountPath: "kubernetes" role: "external-secrets" serviceAccountRef: name: "external-secrets" namespace: "external-secrets" ``` Esse ClusterSecretStore configura o ESO para autenticar com o Vault usando tokens de service account do Kubernetes. O método de autenticação `kubernetes` valida o JWT da service account contra a API TokenReview do cluster. ```yaml # external-secret.yaml # ExternalSecret busca e sincroniza os dados reais do secret apiVersion: external-secrets.io/v1beta1 kind: ExternalSecret metadata: name: database-credentials namespace: production spec: refreshInterval: 1h secretStoreRef: name: vault-backend kind: ClusterSecretStore target: name: db-secret creationPolicy: Owner data: - secretKey: username remoteRef: key: secret/data/production/database property: username - secretKey: password remoteRef: key: secret/data/production/database property: password ``` O ESO consulta o Vault a cada hora (`refreshInterval: 1h`) e atualiza o Secret do Kubernetes automaticamente. A política `creationPolicy: Owner` garante que o Secret seja deletado quando o ExternalSecret for removido. ## Padrões de Integração com HashiCorp Vault O Vault fornece secrets dinâmicos, rotação automática e registro de auditoria completo. O método de autenticação Kubernetes, documentado na [documentação do Vault Kubernetes Auth](https://developer.hashicorp.com/vault/docs/auth/kubernetes), permite que pods se autentiquem sem distribuir credenciais de longa duração. Configurar a autenticação do Vault requer três etapas: ```bash # vault-k8s-auth.sh # Habilitar o método de autenticação Kubernetes no Vault vault auth enable kubernetes # Configurar o Vault para validar tokens contra a API do Kubernetes vault write auth/kubernetes/config \ kubernetes_host="https://kubernetes.default.svc:443" \ kubernetes_ca_cert=@/var/run/secrets/kubernetes.io/serviceaccount/ca.crt # Criar uma role que vincula service accounts a políticas vault write auth/kubernetes/role/external-secrets \ bound_service_account_names=external-secrets \ bound_service_account_namespaces=external-secrets \ policies=readonly-secrets \ ttl=1h ``` Essa configuração vincula a service account `external-secrets` a uma política do Vault. O TTL limita a validade do token, forçando re-autenticação e reduzindo o raio de impacto de tokens comprometidos. Para deploys em produção, a política deve seguir os princípios de menor privilégio: ```hcl # readonly-secrets.hcl # Política do Vault concedendo acesso somente leitura a caminhos específicos path "secret/data/production/*" { capabilities = ["read"] } path "secret/metadata/production/*" { capabilities = ["list"] } ``` Essa política concede acesso de leitura apenas ao caminho de secrets de produção. Times que gerenciam diferentes ambientes recebem políticas separadas com restrições de caminho correspondentes. ## Rotação de Secrets Sem Downtime A rotação automática previne que secrets se tornem vetores de ataque obsoletos. O ESO cuida do lado Kubernetes, mas a aplicação deve recarregar os secrets sem reiniciar. Duas abordagens existem para rotação sem interrupção: **Secrets montados em volume com monitoramento de arquivos:** ```yaml # deployment-volume-secrets.yaml # Montar secrets como arquivos que atualizam automaticamente apiVersion: apps/v1 kind: Deployment metadata: name: api-server spec: template: spec: containers: - name: api image: api:v2.1.0 volumeMounts: - name: secrets mountPath: /etc/secrets readOnly: true volumes: - name: secrets secret: secretName: db-secret ``` O Kubernetes atualiza os arquivos de secrets montados dentro do período de sincronização do kubelet (1 minuto por padrão). A aplicação lê as credenciais de `/etc/secrets/password` a cada conexão com o banco de dados, obtendo os novos valores sem reinício. **Reloader para secrets em variáveis de ambiente:** Aplicações que usam variáveis de ambiente requerem reinícios de pods. O [Stakater Reloader](https://github.com/stakater/Reloader) automatiza esse processo: ```yaml # deployment-with-reloader.yaml # A anotação dispara um reinício gradual quando o secret muda apiVersion: apps/v1 kind: Deployment metadata: name: api-server annotations: reloader.stakater.com/auto: "true" spec: template: spec: containers: - name: api envFrom: - secretRef: name: db-secret ``` O Reloader monitora atualizações de Secrets e realiza reinícios graduais, mantendo a disponibilidade durante toda a rotação. ## Perguntas de Entrevista sobre Secrets no Kubernetes Entrevistas DevOps testam consistentemente a compreensão de gestão de secrets. Essas perguntas aparecem desde níveis junior até senior: **P: Qual codificação os Secrets do Kubernetes usam, e por que é insuficiente para segurança?** Os Secrets usam codificação base64, que é uma transformação reversível, não criptografia. Qualquer usuário com permissões `get` em Secrets pode decodificar os valores. A segurança requer criptografia em repouso (habilitando criptografia do etcd) e restringindo permissões RBAC. **P: Como evitar que secrets apareçam em repositórios Git ao usar GitOps?** O External Secrets Operator armazena apenas referências aos secrets no Git, não os valores em si. O manifesto ExternalSecret contém o caminho para o secret no Vault ou AWS Secrets Manager, enquanto o secret real nunca toca o repositório. Sealed Secrets da Bitnami oferece uma abordagem alternativa usando criptografia assimétrica. **P: Explique a diferença entre SecretStore e ClusterSecretStore.** SecretStore tem escopo de namespace: ExternalSecrets no mesmo namespace podem referenciá-lo. ClusterSecretStore tem escopo de cluster: qualquer namespace pode referenciá-lo. Usa-se ClusterSecretStore quando múltiplos times compartilham uma única instância do Vault, e SecretStore quando cada namespace tem backends de secrets isolados. **P: Como funciona a autenticação Kubernetes no Vault?** Quando um pod se autentica com o Vault, ele envia seu token JWT de service account. O Vault valida esse token contatando a API TokenReview do Kubernetes. Se o token for válido e a service account corresponder a uma role configurada, o Vault emite um token do Vault com as políticas associadas. **P: Qual é a estratégia recomendada para rotação de secrets em um ambiente de produção?** Configurar `refreshInterval` no ExternalSecret abaixo do TTL das credenciais. Para aplicações que usam variáveis de ambiente, fazer deploy do Reloader para automatizar reinícios graduais. Para secrets montados em volume, garantir que a aplicação releia os arquivos ao invés de cachear os valores na inicialização. ## Integração Multi-Cloud com AWS e GCP Organizações que usam múltiplos provedores de nuvem requerem configurações de ESO específicas para cada provedor. AWS utiliza IRSA (IAM Roles for Service Accounts): ```yaml # aws-secret-store.yaml # ClusterSecretStore para AWS Secrets Manager com IRSA apiVersion: external-secrets.io/v1beta1 kind: ClusterSecretStore metadata: name: aws-secrets spec: provider: aws: service: SecretsManager region: eu-west-1 auth: jwt: serviceAccountRef: name: external-secrets-sa namespace: external-secrets ``` A service account recebe uma anotação para vincular a role IAM: ```yaml # service-account-irsa.yaml # Service account com anotação de role IAM apiVersion: v1 kind: ServiceAccount metadata: name: external-secrets-sa namespace: external-secrets annotations: eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/external-secrets ``` A AWS realiza automaticamente a rotação de secrets criados através do Secrets Manager com uma função Lambda. Combinado com o intervalo de refresh do ESO, os secrets se propagam para o Kubernetes dentro do período de polling configurado. ## Sincronização de Secrets Multi-Cluster Organizações que executam múltiplos clusters precisam de distribuição de secrets consistente. Dois padrões abordam esse requisito: **Hub-and-spoke com ClusterSecretStore:** Todos os clusters se conectam a uma instância central do Vault. A instalação do ESO de cada cluster referencia os mesmos secrets, e o Vault gerencia o controle de acesso através de políticas baseadas em namespaces. **Replicação com Vault Enterprise:** O Vault Enterprise suporta replicação de performance entre regiões. Cada cluster se conecta à sua réplica local do Vault, reduzindo latência enquanto mantém consistência. A [documentação de replicação do Vault](https://developer.hashicorp.com/vault/docs/enterprise/replication) cobre os modos de disaster recovery e replicação de performance. ## Hardening de RBAC para Acesso a Secrets As roles de cluster padrão concedem acesso excessivo a secrets. Fortalecer o RBAC criando roles mínimas: ```yaml # restricted-role.yaml # Role permitindo acesso a secrets apenas em um namespace específico apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: secret-reader namespace: production rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get"] resourceNames: ["db-secret", "api-key"] ``` O campo `resourceNames` restringe o acesso aos secrets explicitamente listados. Sem esse campo, a role concede acesso a todos os secrets no namespace. O registro de auditoria captura tentativas de acesso a secrets: ```yaml # audit-policy.yaml # Política de auditoria do Kubernetes para operações de secrets apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: RequestResponse resources: - group: "" resources: ["secrets"] verbs: ["get", "list", "watch"] ``` Essa política registra a requisição e resposta completas para operações de secrets, permitindo que times de segurança detectem padrões de acesso não autorizados. ## Checklist de Produção para Secrets no Kubernetes - Habilitar criptografia do etcd em repouso usando o recurso API `EncryptionConfiguration` - Fazer deploy do External Secrets Operator v0.10+ com ClusterSecretStore apontando para Vault ou provedor de nuvem - Configurar `refreshInterval` abaixo do TTL das credenciais para garantir que os secrets atualizem antes de expirar - Usar IRSA (AWS), Workload Identity (GCP) ou autenticação Kubernetes (Vault) ao invés de credenciais estáticas - Restringir RBAC com `resourceNames` para limitar o acesso a secrets a secrets nomeados específicos - Habilitar registro de auditoria do Kubernetes para operações de secrets com nível RequestResponse - Fazer deploy do Reloader para aplicações que usam variáveis de ambiente para gerenciar atualizações de secrets - Testar a rotação de secrets em staging antes do deploy em produção - Documentar procedimentos de recuperação para interrupções do backend de secrets que afetem o scheduling de pods --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/pt/blog/devops/kubernetes-secrets-management-2026-external-secrets-vault-interview