Secrets - cofres e rotação

Segredo em cloud é qualquer coisa que dá acesso: chave de API, senha de banco, token de serviço, certificado privado. O ponto crítico não é guardar o valor, é controlar quem consegue ler, em que momento, e com qual rastro.

Três práticas se repetem em qualquer arquitetura madura: o segredo vive num cofre (Vault, Secrets Manager, Parameter Store), a aplicação lê em tempo de execução (não em build), e o tempo de vida é curto. Credencial que dura um ano dá para revogar em até 365 dias depois do vazamento, e isso é onde mora o risco real.

Toda semana aparece o mesmo enredo: alguém commita uma Access Key da AWS em um repositório público ou em um chat. Bots de mineradores varrem GitHub em minutos, encontram a chave, validam se ainda funciona e começam a minerar crypto em instâncias reservadas da vítima. A fatura vem antes do alerta.

O detalhe que mata: a chave estava em uma variável de ambiente, então o time achava que não tinha 'commitado segredo'. Mas o .env.example com placeholder, o screenshot do painel da cloud, o log do CI com o valor impresso... cada um desses vaza. Varrer 'AWS_ACCESS_KEY_ID' no repositório antes do merge é higiene básica que quase ninguém faz.

O caminho velho é estático: cria um usuário IAM para a aplicação, gera Access Key + Secret, cola no .env e roda. O segredo fica válido até alguém revogar, e cada deploy novo multiplica quem tem cópia dele.

O caminho moderno é identidade de workload. No AWS chama IRSA (IAM Roles for Service Accounts), no GCP é Workload Identity, no Azure é Workload Identity Federation. A ideia é a mesma: o cluster (EKS, GKE, AKS) recebe um token curto para o pod, e a cloud troca esse token por credenciais temporárias via STS/OIDC. Não existe secret estático para vazar.

Quando o workload não pode assumir identidade federada (caso comum em serviços antigos ou em SaaS de terceiros), a alternativa é buscar o segredo no cofre na inicialização da aplicação, montar em memória e nunca persistir em disco.

A diferença entre buscar em runtime e copiar em build é a diferença entre o segredo existir em uma imagem Docker (que alguém pode abrir) e existir só na heap do processo em execução. O segundo cenário ainda pode vazar via log ou dump, mas é ordens de grandeza mais difícil.

Rotação é o exercício de substituir um segredo antes que ele expire sozinho ou que alguém o tenha comprometido. Cofres modernos tratam isso como cidadão de primeira: Secrets Manager tem rotação automática via Lambda, Vault tem dynamic secrets que expiram em minutos, Parameter Store suporta rotação por evento.

A regra prática: se você não consegue rotacionar a chave sem downtime, você não consegue revogar a chave sob pressão. E sob pressão é quando a revogação precisa acontecer.