PLATFORMS Signal 479
How Pinterest Secures AWS Infrastructure at Scale with a Centralized Terraform Pipeline
↗
Pinterest introduced a centralized Terraform execution pipeline that adds least-privilege controls and dual-review requirements to its AWS infrastructure as code workflows.
Engineers gain a single point to enforce security guards across many repositories, reducing the risk of over-privileged CI/CD systems. The pipeline separates planning from applying and validates workspace-specific backends before any changes are made, which helps prevent accidental state corruption. Teams can adopt a similar pattern without waiting for a full mono-repo migration.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
The pipeline runs as a central set of composite GitHub Actions that splits each pull request into separate plan and apply steps for every affected Terraform workspace.
Before assuming a workspace-specific IAM role, it validates that the Terraform code path matches the workspace’s S3 backend and KMS key to guard against cross-workspace state corruption.
All changes require both an approved code review and an explicit comment on the pull request before the apply step can execute.
THE READ
What the cluster adds up to.
Pinterest shifted from per-repository Terraform scripts to a central set of composite GitHub Actions that run on pull request events. This centralization provides a single control point for enforcing least-privilege access through OIDC-based role chaining. Each workflow first assumes a limited RPPActionsRole that is tied to pre-authorised GitHub workflows. The role reads a source-of-truth configuration file that maps workspaces to repositories, directories, owning teams, and execution IAM roles.
Adopting the pattern requires teams to maintain that source-of-truth file and to implement the backend-block validation step. The validation checks that the Terraform code path aligns with the workspace’s designated S3 backend and KMS key before down-scoping to the workspace-specific role. Only after the check passes does the pipeline run terraform fmt, plan, and, after a clear human comment on the PR, apply the changes. Every code change also needs sign-off from an approved reviewer on the owning repository.
The system stops working if the backend-block validation is mis-configured or if the S3 backend or KMS key for a workspace is incorrect, because the guardrail that prevents cross-workspace state corruption would fail. It does not protect against logical errors within the Terraform code itself; those must be caught by static analysis or testing. Additionally, the pipeline relies on the correctness of the OIDC token validation and the chained-role model; any mis-configuration there could over-privilege a run.
With only one feed describing the event, there is no cross-source corroboration to compare alternative designs or to validate the claimed benefits. The description reflects Pinterest’s internal solution and does not include independent verification of its effectiveness in other organisations.
Although the architecture uses standard OIDC-based role chaining and workspace-to-role mapping, the implementation is private and not open-source. Teams wishing to replicate the approach must build similar composite actions, validation scripts, and dual-control mechanisms using the same publicly available AWS and GitHub features.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER