Migrar os secrets do onion-backend de SOPS para ward

TLDR: Substitui os arquivos de secret encriptados com SOPS por um único vault ward e troca o CI de infra (tanto o reusable pipelines/infra.yml@v2 quanto o infra-pr.yml local do repo) de SOPS_AGE_KEY para ward (@v3 + ward_path + WARD_KEY) — alinhando com o modelo do marketing/gateway.

Contexto

O onion-backend encripta os secrets do Terraform com SOPS (.infra/terraform/secrets/*.enc.yml) e: - infra.yml chama o reusable ibft-corp/pipelines/.github/workflows/infra.yml@v2 com SOPS_AGE_KEY_STAGING/PRODUCTION - infra-pr.yml é um workflow local do repo que escreve a age key em .infra/terraform/secrets/staging.key e decripta inline — o que divirge do padrão reusable e também precisa migrar para ward

O repo marketing já migrou esse padrão para ward (vault único, pipelines/infra.yml@v3, ward_path + WARD_KEY); o @v3 suporta ward nativamente. Esta spec traz o onion-backend para o mesmo modelo.

Chaves de secret hoje: app_version, secret_key, jwt_secret, rabbitmq_admin_password, rabbitmq_onion_password, celery_broker_url, dd_api_key, cloudflare_api_token, cloudflare_zone_id, do_token (staging; production análogo).

Nota: o onion-backend consome o messagebroker compartilhado (rabbitmq_*) — igual ao marketing. Se/quando apontar para o Amazon MQ, esse é um cutover separado.

Objetivos

  • Secrets do onion-backend vivem em um único vault ward (um vault, sub-arquivos por ambiente mesclados — como no marketing)
  • Ambos infra.yml e infra-pr.yml usam o fluxo ward; o infra-pr.yml local com SOPS é substituído pelo workflow reusable de plan baseado em ward (ou reescrito para usar ward exec)
  • Arquivos SOPS, .sops.yaml, tratamento de *.key e os make targets de SOPS removidos

Fora de escopo

Esta spec migra apenas o mecanismo de secrets, não o alvo do broker.

Mudanças

Vault ward — .ward/

  • Criar .ward/config.yaml com um único vault onion-backend (espelhando o do marketing)
  • Criar .ward/vaults/onion-backend/ com um arquivo base + sub-arquivos staging/production contendo as chaves TF_VAR_* migradas dos .enc.yml. Um vault lógico; separação por ambiente via sub-arquivo

.github/workflows/infra.yml

  • Subir pipelines/.github/workflows/infra.yml@v2 → @v3; adicionar ward_path: onion-backend (+ working_directory se necessário)
  • Remover SOPS_AGE_KEY_*; adicionar WARD_KEY: ${{ secrets.WARD_KEY }}

.github/workflows/infra-pr.yml

  • Substituir o decrypt SOPS local (age key → arquivo .key → sops inline) pelo plan baseado em ward — idealmente chamando o workflow reusable de PR-plan dos pipelines em @v3, do mesmo jeito que o marketing, ou ward exec -- terraform plan se mantido inline. Sem age key e sem arquivo .key

Remover SOPS

  • Deletar .infra/terraform/secrets/*.enc.yml, qualquer *.key, .sops.yaml e os make targets de SOPS

Como verificar

  • CI de infra (PR plan + apply na main) roda verde via ward — sem steps de SOPS/age em nenhum dos dois workflows
  • grep -rn "sops\|SOPS_AGE\|\.enc\.yml" .github/ .infra/ → nenhum match
  • terraform plan resolve os mesmos valores a partir do ward (sem diff)

Notas para o agente executor

  • Ler ibft-corp/pipelines/.github/workflows/infra.yml@v3 (ou copiar o infra-main.yml + infra-pr.yml do marketing) para os inputs exatos — o marketing é a referência funcionando
  • O infra-pr.yml local é a parte mais delicada: hoje não usa o workflow reusable. Preferir migrar para o PR-plan reusable com ward; só manter customizado se houver motivo
  • Um vault, sub-arquivos por ambiente mesclados — não um vault por ambiente
  • Migrar os valores antes de deletar o SOPS; verificar que um plan resolve. O secret WARD_KEY do GitHub precisa existir (passo de admin)

Documentação

Atualizar a documentação de infra / README que referencia SOPS para descrever o fluxo ward.