How Pinterest Secures AWS Infrastructure at Scale with a Centralized Terraform Pipeline

Follow us on

Pinterest has revealed the Resource Provisioner Pipeline (RPP), its own Terraform execution engine. It ensures least-privilege access and needs dual-control reviews. This is important for the company’s AWS infrastructure, as it adds strict guardrails to the GitHub Actions workflows. The system handles many Terraform workspaces, which control thousands of cloud resources. This includes IAM policies, VPCs, load balancers, S3 buckets, and Kubernetes clusters.

Pinterest's Terraform code is scattered across many repositories. Each one is owned by a different team. A consolidation into a mono-repo is still in progress. Granting a CI/CD system wide permissions to make changes across many repositories and AWS accounts can lead to a big risk. This increases the chances of accidental misconfigurations and malicious actions. RPP was built as a bridge that secures this multi-repo reality without waiting for the underlying consolidation to finish.

RPP activates on GitHub pull request events. It runs as a central set of composite GitHub Actions instead of per-repo scripts. This approach splits a single PR into separate plan/apply runs for each affected workspace. Execution uses a chained-role model. First, a workflow takes on a central RPPActionsRole. This role is limited to certain pre-authorised GitHub workflows through OIDC token validation. That role reads a source-of-truth configuration file. This file maps each workspace to its allowed repository, working directory, owning team, and execution IAM role. Before down-scoping, RPP checks that the Terraform code path matches the specific S3 backend and KMS key for that workspace. This helps catch mistakes where a developer might accidentally link one workspace's directory to another's state file. The pipeline takes on the workspace-specific team role only after the check passes. Then, it runs `terraform fmt`, `plan`, and, after a clear human comment on the PR, it applies the changes. All code changes additionally require sign-off from an approved reviewer on the owning repository.

Pinterest says the model provides a single control point for fixes across the infrastructure. This means a systemic issue, like a weak CI runner shell, can be fixed in one place instead of in hundreds of separate repositories. The centralized composite actions help the team run consistent PR-triggered checks. This includes static analysis with custom Semgrep rules and AI-assisted scanning. They can also do optional LocalStack-based dry runs to test against mocked AWS behaviour before changes affect real accounts.

RPP is a private system, not open-source. The architecture uses standard OIDC-based role chaining and workspace-to-role mapping. However, the strong focus on backend-block validation is important. It acts as a guardrail against cross-workspace state corruption. This detail is key for teams using similar multi-repo Terraform setups.

The workspace-path-role mapping pattern is a helpful guide. It includes source-of-truth config, backend validation, and down-scoped role assumption. Teams can use it to enforce least privilege in PR-driven Terraform pipelines without needing a full mono-repo migration. Dual control has two layers: a human code review approval and a clear PR comment needed to trigger the apply. This keeps planning and applying as separate, auditable actions.

Securing centralised IaC pipelines is a well-known challenge. Mercari had a similar issue with its Terraform monorepo. It started with one broad GCP service account that had owner rights for all projects. To fix this, Mercari used GCP's tools. They paired keyless Cloud Build credentials with a read-only "plan" account and a specific "apply" account for each service. They used impersonation to limit each job's impact to one project.

Slack chose a different approach. They decentralized state ownership to individual teams. However, they still enforce a plan-then-apply gate. Changes must go through sandbox and development before reaching production. RPP stands out because it includes a clear backend and KMS-key validation step. This step checks a workspace's Terraform code path against its state file before any role is assumed. It acts as an extra defence, adding to a role-mapping model similar to what Mercari and Slack use. This helps keep centralized IaC pipelines safe from becoming a single point of failure.

Related Topics:

• DevOps
• Terraform
• GitHub Actions
• Cloud Security
• AWS

We protect your privacy.