Como o Pinterest protege sua infraestrutura AWS com um pipeline Terraform centralizado

O Pinterest apresentou o Resource Provisioner Pipeline (RPP), seu próprio motor de execução de Terraform que aplica acesso de menor privilégio e exige revisões com controle duplo, segundo reportagem da InfoQ. O sistema adiciona proteções aos fluxos de trabalho do GitHub Actions e gerencia muitos workspaces do Terraform que controlam milhares de recursos na nuvem, incluindo políticas IAM, VPCs, load balancers, buckets S3 e clusters Kubernetes.

O problema: código espalhado em muitos repositórios

O código Terraform do Pinterest está distribuído por vários repositórios, cada um pertencente a um time diferente. Uma consolidação em mono-repo ainda está em andamento. O ponto de atenção, segundo a empresa, é que conceder a um sistema de CI/CD permissões amplas para alterar múltiplos repositórios e contas AWS aumenta o risco de configurações incorretas acidentais e ações maliciosas.

O RPP foi construído como uma ponte que protege essa realidade multi-repo sem esperar a consolidação terminar.

Como o pipeline funciona

O RPP é acionado por eventos de pull request no GitHub e roda como um conjunto central de composite GitHub Actions, em vez de scripts por repositório. Ele divide um único PR em execuções separadas de plan/apply para cada workspace afetado.

A execução usa um modelo de encadeamento de roles:

• Um workflow assume primeiro uma role central, a RPPActionsRole, limitada a workflows pré-autorizados via validação de token OIDC.
• Essa role lê um arquivo de configuração que funciona como fonte de verdade, mapeando cada workspace ao seu repositório permitido, diretório de trabalho, time responsável e role IAM de execução.
• Antes de reduzir o escopo, o RPP verifica se o caminho do código Terraform corresponde ao backend S3 e à chave KMS específicos daquele workspace.
• Só depois dessa checagem o pipeline assume a role específica do time e roda terraform fmt, plan e, após um comentário humano explícito no PR, aplica as mudanças.

Toda alteração de código também exige aprovação de um revisor autorizado no repositório dono. A verificação do bloco de backend serve como proteção contra corrupção de estado entre workspaces, evitando que um desenvolvedor vincule por engano o diretório de um workspace ao arquivo de estado de outro.

Um ponto único de controle

Segundo o Pinterest, o modelo oferece um único ponto de controle para correções em toda a infraestrutura. Um problema sistêmico, como um shell frágil no runner de CI, pode ser corrigido em um só lugar em vez de em centenas de repositórios separados.

As composite actions centralizadas permitem checagens consistentes disparadas por PR, incluindo análise estática com regras customizadas de Semgrep, escaneamento assistido por IA e execuções de teste opcionais com LocalStack, que simulam o comportamento da AWS antes que as mudanças afetem contas reais.

O RPP é um sistema privado, não open source. A arquitetura usa encadeamento de roles baseado em OIDC e mapeamento de workspace para role, padrões já conhecidos, mas o foco forte na validação do bloco de backend é o diferencial destacado pela InfoQ.

O que isso muda para times BR

O padrão de mapeamento workspace-caminho-role serve como guia prático para times que crescem e ainda não têm um mono-repo. Ele combina três elementos: configuração como fonte de verdade, validação de backend e assunção de role com escopo reduzido. Isso permite reforçar o menor privilégio em pipelines de Terraform disparados por PR sem esperar uma migração completa, algo comum na realidade de empresas brasileiras que acumularam repositórios ao longo do tempo.

O controle duplo tem duas camadas: aprovação humana de code review e um comentário explícito no PR para disparar o apply, mantendo o planejamento e a aplicação como ações separadas e auditáveis.

Proteger pipelines de IaC centralizados é um desafio conhecido. A Mercari teve problema semelhante em seu monorepo Terraform, que começou com uma única service account de amplo poderno GCP, e resolveu pareando credenciais keyless do Cloud Build com uma conta de leitura para o plan e uma conta específica de apply por serviço, usando impersonation. Já o Slack optou por descentralizar a propriedade do estado entre os times, mas ainda impõe um portão de plan-then-apply, com mudanças passando por sandbox e desenvolvimento antes de chegar à produção.

Fonte: InfoQ