Migrar os secrets para ward

TLDR: Substituir SOPS+age e o .env em 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.sh por ward 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 .env por completo.

Fora de escopo

  • Auditar se src/stacks/ inteiro é duplicata de src/ e pode ser removido — pendência anotada, não resolvida aqui.

Mudanças

Arquivos novos

  • .ward/config.yaml — configuração do ward (chave via key_env: WARD_KEY no CI, key_file: .ward.key local).
  • .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 em ward exec --.
  • Variáveis do Terraform — renomeadas para MAIÚSCULA, para casar com a injeção do ward.
  • bin/stacks/*/apply.sh — o terraform init passa -backend-config com TERRAFORM_BACKEND_ACCESS_KEY e TERRAFORM_BACKEND_SECRET_KEY, isolando a credencial do backend de outros usos de S3.
  • .github/workflows/infra.yml — bloco de decriptação SOPS substituído por WARD_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.