Container registry como componente de plataforma e secrets do GitHub via Terraform

TLDR: Promover o container registry a componente de primeira classe da camada de plataforma (junto com VPC e state storage) e passar a gerir os secrets de infraestrutura do GitHub por Terraform, para que o CI/CD seja reproduzível a partir do código.

Contexto

Durante o deploy do gateway no Kubernetes três coisas ficaram claras:

  1. O container registry é um componente fundacional de plataforma, na mesma categoria que a VPC e o storage de state — não um detalhe de aplicação.
  2. Os secrets do GitHub deveriam ser geridos por Terraform, para reprodutibilidade.
  3. O registry precisa expor outputs em remote state para que outros stacks o referenciem.

Objetivos

  • Stack de plataforma dedicado ao registry, com outputs consumíveis por remote state.
  • Deploy idempotente com auto-import (registry criado à mão é importado, não recriado).
  • Secrets de infraestrutura do GitHub geridos por Terraform.
  • O registry entra no fluxo de bootstrap, como passo 3.

Fora de escopo

  • Secrets de aplicação (REDIS_PASSWORD, SECRET_KEY_BASE) — continuam manuais via gh secret set. Eles não derivam do ciclo de vida da infraestrutura, precisam de rotação independente e assim ficam menos expostos no state do Terraform.
  • Registry em múltiplos provedores, webhook de push, scanning de vulnerabilidade, garbage collection e políticas de retenção — listados como melhoria futura.
  • Mudanças no repo do gateway: os secrets são geridos a partir do repo de infraestrutura.

Mudanças

1. Stack do registry de plataforma

src/platform/registry/terraform/ com backend.tf, versions.tf, variables.tf, main.tf e outputs.tf. Tier configurável (default basic), outputs de endpoint e server_url, deploy idempotente com auto-import e conexão do registry ao cluster para permitir o pull de imagem.

Variáveis novas: TF_VAR_platform_registry_name, TF_VAR_platform_registry_region, TF_VAR_platform_registry_tier.

2. Scripts

bin/platform/registry/ com sete scripts no padrão de plataforma: deploy.sh (conecta o registry ao Kubernetes automaticamente), status.sh (lista repositórios e uso de storage), plan.sh, init.sh, outputs.sh, health.sh (valida o secret docker-registry no cluster) e destroy.sh.

3. Makefile

makefiles/platform.mk ganha platform.registry.{init,apply,plan,status,outputs,health,destroy}. Os targets agregados (platform.apply, platform.status, platform.health, platform.destroy) passam a incluir o registry — no destroy ele vem antes da rede.

4. Bootstrap

bin/helpers/bootstrap/main.sh ganha o registry como passo 3, depois do backend de state e da VPC.

5. Secrets do GitHub

Novo src/stacks/shared/gateway/terraform/github-secrets.tf, mais o provider GitHub em versions.tf/provider.tf, as variáveis github_token e gh_actions_ssh_key, e o remote state do registry em data.tf.

A linha divisória:

Secret Gerido por Terraform? Por quê
token do registry ✅ credencial de infraestrutura, atrelada ao ciclo de vida do token do provedor
KUBE_CONFIG ✅ derivado do state do cluster
GH_ACTIONS_IBFTCORP_SSH_KEY ✅ credencial de infraestrutura, longa duração
REDIS_PASSWORD ❌ secret de aplicação, rotação independente
SECRET_KEY_BASE ❌ secret de aplicação, rotação independente

Ambientes do GitHub: staging com deploy automático, production com aprovação manual.

Fluxo de dado

mermaid graph TD A["bootstrap cria o registry"] --> B["state: platform/registry"] B --> C["terraform do gateway lê via data.terraform_remote_state.registry"] C --> D["cria os secrets do GitHub"] D --> E["GitHub Actions: login no registry, push da imagem, deploy no cluster"]

Como verificar

```bash make platform.registry.status # nome, endpoint, storage, lista de repositórios make platform.registry.health # registry acessível + secret no cluster

gh secret list –repo ibft-corp/gateway # secrets de repositório gh secret list –env staging –repo ibft-corp/gateway # secrets de ambiente ```

Depois, um push no repo do gateway deve fazer login no registry, buildar, dar push e deployar sem intervenção.

Rollback: comentar o github-secrets.tf e voltar a gerir os secrets pelo gh. O registry pode ficar — não afeta aplicação em execução. make platform.registry.destroy apaga todas as imagens.

Documentação

  • .env.example — variáveis novas do registry e do token do GitHub.
  • CLAUDE.md.

Nota histórica: o registry desta spec é o DOCR. Ele foi substituído pelo ECR na conta shared (migração do registry para ECR) e o stack src/platform/registry está marcado para remoção (descomissionar DOCR). A gestão de organization secrets sobreviveu, hoje em src/shared/github.