Regra de make para liberar IP no banco

TLDR: Criar uma regra de make no commons que autoriza o IP público atual (ou um informado) no security group do banco na nuvem, lendo os identificadores de recurso de um arquivo de config genérico por projeto.

Sucessão: a spec 20260731210414_remove_db_ip_allow_improve_help propõe remover a regra db.ip.allow, já que o security group do cluster de leads passou a liberar 0.0.0.0/0 na 5432. Enquanto aquela spec não for implementada, esta continua valendo.

Contexto

O projeto marketing está migrando seu banco para um Postgres gerenciado na nuvem (AWS Aurora, provisionado manualmente por ora). O cluster é alcançável pela internet pública, mas protegido por um security group que só libera a porta 5432 para IPs autorizados. Os IPs dos devs e do time são dinâmicos, então a lista precisa ser atualizada com frequência.

Hoje isso é uma chamada manual de aws ec2 authorize-security-group-ingress. Queremos uma regra de make reutilizável e agnóstica de projeto (no commons), que qualquer projeto migrando para banco na nuvem possa usar, com os identificadores de recurso guardados por projeto num arquivo de config genérico (sem nome de provider no nome do arquivo).

Objetivos

  • Um único comando (make db.ip.allow) para autorizar um IP público no security group do banco
  • Manter os identificadores de recurso (security group, região, profile, cluster) num arquivo de config genérico por projeto — não hardcoded no script
  • Viver no commons (shell/tasks/), para ser reutilizável entre projetos, ligado via make/shared/infra.mk
  • Usar por padrão o IP público de quem chama, permitindo passar um IP/CIDR explícito

Fora de escopo

— (não registrado na spec original)

Mudanças

Commons (~/workspace/wehive.tech/.commons)

  • shell/tasks/infra/db/ip/allow.sh (novo): resolve a raiz do projeto, carrega a config genérica de provider, determina o IP (argumento ou IP público atual via checkip.amazonaws.com) e roda aws ec2 authorize-security-group-ingress. Idempotente (ignora “rule already exists”).
  • make/shared/infra.mk (editar): adicionar o target db.ip.allow, delegando para a task: @$(COMMONS_DIR)/shell/tasks/infra/db/ip/allow.sh $(IP).

Projeto marketing (automation/.infra/)

  • automation/.infra/provider-args (novo): config de infra genérica, agnóstica de provider, consumida pela task. Chaves (valores do cluster manual atual):
    • DB_SECURITY_GROUP=sg-00fa8b2d9c1060781
    • DB_REGION=us-east-1
    • DB_CLUSTER=automation-vpc-1
    • CLOUD_PROFILE=admin-access-970959930130

Como verificar

```bash # a partir do projeto marketing/automation make db.ip.allow # autoriza o IP público atual make db.ip.allow IP=1.2.3.4/32 # autoriza um CIDR explícito

depois, confirmar que a regra existe:

AWS_PROFILE=admin-access-970959930130 aws ec2 describe-security-groups \ –group-ids sg-00fa8b2d9c1060781 –region us-east-1 \ –query ‘SecurityGroups[0].IpPermissions’ ```

Documentação

  • learnings/database_aurora_password_authentication.md — registra por que o cluster Aurora manual usa acesso público restrito por security group: o relay de conectividade gerenciada (“internet access gateway”) força autenticação IAM, então autenticação por senha exige um cluster numa VPC própria. É a decisão arquitetural por trás desta regra.