Como você lida com segredos em um pipeline de build e deploy?

Mantenha credenciais de vida longa completamente fora do pipeline. Use federação de identidade de carga de trabalho para que o job de CI troque um token OIDC de curta duração por uma role com escopo limitado, e busque os segredos da aplicação em tempo de execução em um gerenciador de segredos, em vez de injetá-los no build. Limite cada segredo a um ambiente e a um consumidor, rotacione automaticamente, audite o acesso e mascare nos logs. Nunca embuta segredos em imagens nem faça commit deles, mesmo criptografados, sem gestão de chaves.

A minha posição de partida é que o pipeline não deve segurar nenhuma credencial de nuvem de vida longa. O provedor de CI emite um token de identidade assinado para o job, a nuvem confia naquele emissor, e o job troca isso por uma role que dura minutos e tem escopo de um ambiente só. Isso elimina toda a categoria de uma chave estática vazada parada em uma configuração de repositório por três anos. Segredos de aplicação são uma preocupação separada e pertencem ao tempo de execução, buscados em um gerenciador de segredos pela própria carga de trabalho usando a identidade dela, então uma senha de banco nunca passa pelo build. Se eu preciso manter segredos criptografados no git, por exemplo em um repositório GitOps, eles são criptografados contra um serviço de gestão de chaves, então o que eu de fato controlo é o direito de descriptografar e não o arquivo. Tudo fica com escopo estreito, rotacionado em um cronograma, e o acesso é logado. E eu me planejo para vazamentos: revogar primeiro, rotacionar, e só então calcular o raio de impacto pela trilha de auditoria, porque tentar provar que ninguém usou antes de revogar é a ordem errada.