Lidando com secrets em um repositório de manifests do Argo CD

Três abordagens, na ordem em que eu escolheria hoje. Prefira o External Secrets Operator para a maioria dos times. Prefira Sealed Secrets se você não tem um gerenciador de secrets externo. Evite configurações baseadas só em SOPS para times maiores que um punhado de pessoas, porque a distribuição de chaves complica rápido. External Secrets Operator (ESO). O secret de verdade vive no AWS Secrets Manager, Vault, GCP Secret Manager ou similar. No Git você commita um ExternalSecret CR que diz 'busque esta chave naquele store e crie um Secret do Kubernetes chamado X no namespace Y'. O Argo CD sincroniza o ExternalSecret. O ESO faz a busca. Nenhum texto cifrado no Git, o gerenciador de secrets cuida da rotação, o IAM controla o acesso. É essa a minha escolha padrão. Sealed Secrets (Bitnami). Você roda o controller sealed-secrets no cluster. Ele gera uma chave pública. Você criptografa os secrets localmente com o kubeseal usando essa chave pública. O SealedSecret CR criptografado é seguro para commitar. O controller descriptografa dentro do cluster e cria um Secret normal. A chave pública é por cluster, então um SealedSecret criptografado para dev não funciona em prod. Isso é uma vantagem, não um problema. Layout do repositório com ESO (por ambiente, já que as referências de secret mudam): apps/ web/ base/ external-secret.yaml # template com placeholders kustomization.yaml overlays/ dev/ external-secret-patch.yaml # ajusta secretStoreRef + caminho da chave remota prod/ external-secret-patch.yaml platform/ external-secrets/ cluster-secret-store-dev.yaml cluster-secret-store-prod.yaml Layout do repositório com Sealed Secrets: apps/ web/ base/ deployment.yaml kustomization.yaml overlays/ dev/ sealed-secret.yaml # criptografado com a chave pública do cluster dev prod/ sealed-secret.yaml # criptografado com a chave pública do cluster prod Coisas que eu nunca faço, independentemente da abordagem: 1. Nenhum manifest de Secret em texto plano no Git, nem mesmo em base64. Base64 não é criptografia. 2. Nenhuma chave única compartilhada entre todos os ambientes. Todo o objetivo é que uma chave de dev vazada não consiga descriptografar secrets de prod. 3. Nenhum valor de secret em parâmetros de Application do Argo CD ou em arquivos de values do Helm commitados no Git, porque eles acabam parando na memória do argocd-server e no histórico do CLI. 4. Sem misturar abordagens: escolha uma por cluster. Dois sistemas significam o dobro da dor de rotação e ownership pouco claro. Uma pegadinha específica do Argo CD. Quando o ESO ou o sealed-secrets cria o Secret subjacente, o Argo CD pode mostrar a Application pai como OutOfSync porque o Secret que ela criou não está rastreado no Git. Adicione o Secret em ignoreDifferences, ou anote o ExternalSecret/SealedSecret para que o Argo CD saiba que o Secret filho é gerenciado por outro controller. Caso contrário, o self-heal vai brigar com o controller de secrets e você terá loops de reconciliação.