Migrar os secrets para ward
TLDR: Substituir SOPS+age e o
.envem texto puro por ward, unificando a gestão de secret no desenvolvimento local e no CI/CD num único vault criptografado commitado no repo.
Contexto
O projeto geria secret de duas formas paralelas:
| Onde | Como |
|---|---|
| local | .env em texto puro (gitignored), preenchido à mão via setup-credentials.sh |
| CI/CD | secrets/infra.enc.yml criptografado com SOPS+age, decriptado no Actions via SOPS_AGE_KEY |
Isso gera risco de drift e manutenção duplicada. O ward unifica os dois fluxos: um vault criptografado commitado no repo, decriptado localmente via .ward.key e no CI via a variável WARD_KEY.
Objetivos
- Inicializar o ward no projeto e migrar todos os secrets do arquivo SOPS para o vault.
- Substituir o fluxo local
.env+setup-credentials.shporward exec -- make <target>. - Substituir a decriptação SOPS no CI pelo GitHub Secret
WARD_KEY+ward exec. - Remover SOPS, age e o setup baseado em
.envpor completo.
Fora de escopo
- Auditar se
src/stacks/inteiro é duplicata desrc/e pode ser removido — pendência anotada, não resolvida aqui.
Mudanças
Arquivos novos
.ward/config.yaml— configuração do ward (chave viakey_env: WARD_KEYno CI,key_file: .ward.keylocal)..ward/vault/infra.ward— vault criptografado com todos os secrets (commitado)..ward.key— chave age local (gitignored).
Arquivos modificados
.gitignore— adiciona.ward.key.Makefile/makefiles/— targets de topo envolvidos emward exec --.- Variáveis do Terraform — renomeadas para MAIÚSCULA, para casar com a injeção do ward.
bin/stacks/*/apply.sh— oterraform initpassa-backend-configcomTERRAFORM_BACKEND_ACCESS_KEYeTERRAFORM_BACKEND_SECRET_KEY, isolando a credencial do backend de outros usos de S3..github/workflows/infra.yml— bloco de decriptação SOPS substituído porWARD_KEY+ward exec.
Arquivos removidos
secrets/infra.enc.yml, secrets/infra.key, .sops.yaml, bin/helpers/setup/setup-credentials.sh e .project/make/secrets.mk.
Secrets migrados
O ward injeta variável de ambiente em MAIÚSCULA, então as variáveis do Terraform são renomeadas para casar com TF_VAR_<NAME> exatamente. A migração é feita por stack — o messagebroker foi o piloto.
DO_TOKEN, DD_API_KEY, CLOUDFLARE_API_TOKEN, CLOUDFLARE_ZONE_ID, DOMAIN, GITHUB_TOKEN, DOCR_TOKEN, SHARED_MESSAGEBROKER_ADMIN_PASSWORD, SHARED_MESSAGEBROKER_SUBDOMAIN, DROPLET_SSH_KEYS, KUBERNETES_VERSION, TERRAFORM_BACKEND_ACCESS_KEY, TERRAFORM_BACKEND_SECRET_KEY.
Como verificar
```bash # local ward envs # lista todas as TF_VAR_* ward exec – make mkt.plan # plan com os secrets injetados
CI
# abrir uma branch e conferir que o Actions roda sem o passo de SOPS e o plan passa ```
Documentação
- Guia do vault ward — fluxo de adicionar/editar secret e como o CI usa a
WARD_KEY. - Remover toda referência a SOPS/age da documentação existente.
Nota: a decisão de MAIÚSCULA foi revertida depois. Os stacks migrados na migração completa para ward usam nome minúsculo, e o ward mapeia
TF_VAR_<name>direto. O layout final do vault é.ward/vaults/{infrastructure,bootstrap}/, não.ward/vault/infra.ward.