Pinterest 公布了其自主研发的 Terraform 执行引擎——资源配置器管道（RPP）。该引擎可以确保遵循最小权限原则，并且需要双重控制审核。这对该公司的 AWS 基础设施至关重要，因为它为 GitHub Actions 工作流增添了严格的防护措施。该系统管理着众多 Terraform 工作区，其中控制着数千个云资源，包括 IAM 策略、VPC、负载均衡器、S3 存储桶和 Kubernetes 集群。
Pinterest 的 Terraform 代码分散在多个代码库中，每个代码库由不同的团队负责。目前，将这些代码库整合为一个代码库的工作仍然在进行当中。若授予 CI/CD 系统跨多个代码库和 AWS 账户进行更改的系统级权限，可能会带来巨大的风险。这会增加意外配置错误和恶意操作的发生概率。RPP 的构建旨在充当一座桥梁，在无需等待底层整合完成的情况下，确保这种多代码库环境的安全。
RPP 在 GitHub 拉取请求事件触发时启动。它是作为一组集中式的复合 GitHub Actions 来运行，而非按代码库执行的脚本。这种方法将单个拉取请求拆分为针对每个受影响工作区的独立 plan/apply 来运行。其执行过程采用链式角色模型。首先，一个工作流承担中央 RPPActionsRole 角色。借助 OIDC 令牌验证机制，该角色仅限于某些预先授权的 GitHub 工作流。该角色会读取一个“权威数据源”配置文件。该文件中保存着每个工作区与允许访问的代码库、工作目录、所属团队以及 Execution IAM 角色的映射。在缩小作用域之前，RPP 会检查 Terraform 的代码路径是否与特定于该工作区的 S3 后端和 KMS 密钥相匹配。开发人员可能无意中将一个工作区的目录链接到另一个工作区的状态文件，该检查有助于发现由此所引发的错误。只有在检查通过后，该管道才会承接特定于工作区的团队角色。随后，它会运行 terraform fmt 和 plan 命令，并在拉取请求（PR）获得明确的人工评论后应用这些更改。此外，所有代码更改都需要经过所属代码库中已获授权的审阅者签批。
执行模型
Pinterest 表示，该模型为整个基础设施的修复提供了单一控制点。这意味着系统性问题（如 CI 运行器 shell 存在漏洞）只需要在一个地方修复，而不需要在数百个独立的代码库中分别处理。这些集中式的复合操作有助于团队运行由拉取请求（PR）触发的一致性检查，其中包括基于自定义 Semgrep 规则的静态分析以及 AI 辅助扫描。此外，在变更影响真实账户之前，团队还可以选择性地基于 LocalStack 进行干跑测试，以模拟 AWS 行为进行验证。
RPP 是一个私有系统，并未开源。其架构采用了基于标准 OIDC 的角色链和工作区到角色的映射。不过，至关重要的是要重视对后端块的验证。当跨工作区状态出现损坏时，它可以起到防护作用。对于使用类似多代码库 Terraform 配置的团队而言，这一细节至关重要。
“工作区-路径-角色”这一映射模式提供了一份有用的指南。它包含“权威数据源”配置、后端验证以及降权角色承接。团队可以利用该模式，在基于 PR 的 Terraform 管道中强制实施最小权限原则，而不需要完整地迁移一个单体代码库。双重控制包含两个层：人工代码评审审批，以及触发 apply 操作所需的明确 PR 评论。这确保了 plan 和 apply 是作为两个相互独立且可审计的操作。
众所周知，保障集中式基础设施即代码（IaC）管道的安全性是一项不小的挑战。Mercari 在其 Terraform 单体代码库中也遇到了类似的问题。起初，他们使用了一个拥有所有项目所有者权限的通用 GCP 服务账户。为解决此问题，Mercari 采用了 GCP 的工具。他们将无密钥的 Cloud Build 凭据与一个只读的 “plan” 账户以及每个服务专用的 “apply” 账户配对使用。通过模拟身份机制，将每个任务的影响范围限制在单个项目内。
Slack 则选择了不同的方法。他们将状态所有权下放给各个团队。不过，他们仍然强制执行“先规划、后应用”的门控机制。变更必须经过沙箱和开发环境，然后才能进入生产环境。RPP 的特别之处在于它包含一个明确的后端和 KMS 密钥验证步骤。该步骤在承接任何角色之前，会将工作区的 Terraform 代码路径与状态文件进行比对。它起到了额外的防护作用，补充了类似于 Mercari 和 Slack 所采用的角色映射模型。这有助于确保集中式基础设施即代码（IaC）管道不会演变为单点故障。
原文链接：https://www.infoq.com/news/2026/08/pinterest-secures-aws-infra/
