Pinterest's Resource Provisioner Pipeline (RPP) for Secure Infrastructure as Code at Scale

The Challenge of Infrastructure as Code at Scale

Managing Infrastructure as Code (IaC) across a large organization with a distributed, multi-repository architecture presents significant security and logistical hurdles. Pinterest developed the Resource Provisioner Pipeline (RPP) to address these challenges, particularly around safely managing both critical and non-critical infrastructure changes in their extensive AWS environment. RPP acts as a vital bridge to securely support Pinterest's legacy multi-repo structure while an initiative to consolidate into a monorepo is underway.

RPP Architecture and Key Principles

• Centralized Execution Model: RPP enforces a centralized execution model via GitHub Actions to maintain absolute control over infrastructure states. Workflows are triggered by Pull Request (PR) events, with composite actions operating directly on the PR.
• Workspace Splitting: A single PR can affect multiple workspaces. RPP isolates the impact by executing individual plans or apply workflows for each workspace independently.
• Dual Controls: To prevent accidental or malicious configurations, all code changes require sign-off from an approved code reviewer on the respective repository, adding a human scrutiny layer.
• Least Privilege with Secure Role-Chaining: This is a core security mechanism. RPP implements a strict workspace-path-role mapping process, ensuring that the CI/CD system operates with the absolute minimal IAM permissions required for a specific change.

Secure Role-Chaining Mechanism

The role-chaining process in RPP is critical for enforcing least privilege. It involves several steps:

1. Assume RPPActionsRole: The system first assumes a centralized `RPPActionsRole`. This role is strictly restricted to be assumed only from pre-authorized GitHub workflows, enforced via GitHub OpenID Connect (OIDC) token validation at the cloud provider layer.
2. Workspace Property Determination: Within the `RPPActionsRole` context, the pipeline consults a central source-of-truth configuration file to map the workspace to its allowed repository name, directory path, team name, and execution role.
3. Strict Backend Validation: A critical check ensures that the Terraform code path strictly references the explicit S3 state backend blocks and KMS keys mapped to that specific workspace, preventing misconfigurations or accidental state corruption.
4. Down-Scoping to Team Execution Role: If validation passes, the `RPPActionsRole` assumes a designated, down-scoped `team_iam_role`. This links specific code paths to specific workspaces and roles, guaranteeing changes are made with minimal required IAM permissions.

Deployment Workflow and Advanced Practices

With the localized `team_iam_role` assumed, the deployment proceeds with fine-grained control, including linting, plan generation published as a PR comment, and deliberate application requiring an explicit PR comment. Beyond access management, the PR-driven workflow enables advanced reliability and security practices like automated vulnerability scanning (Semgrep, Helix/AI) and pre-deployment local testing using LocalStack to mock AWS behavior.

Benefits of Centralization

Consolidating deployment logic into centralized composite execution steps provides Pinterest with significant operational advantages:

• Unified Auditing: Consistent tracking of deployment actions across all infrastructure repositories.
• Instant Systemic Patches: Ability to roll out fixes for widespread vulnerabilities from a single central location.
• Path-to-Workspace Enforcement: Global enforcement of strict path mappings.
• Resource Metrics: Centralized tracking of statistics on cloud resources.
• Policy and Tag Enforcement: Foundation for future automated policy and tag enforcement across all cloud resources.