Pinterest自研RPP引擎：双重审核与最小权限管理数千AWS资源

Pinterest 公布了一项自研基础设施安全方案——资源配置器管道（Resource Provisioning Pipeline，简称 RPP）。这是一套集中式的 Terraform 执行引擎，核心目标是确保 AWS 基础设施遵循最小权限原则，并为每一次变更加入双重控制审核。该系统目前管理着众多 Terraform 工作区，控制着包括 IAM 策略、VPC、负载均衡器、S3 存储桶和 Kubernetes 集群在内的数千个云资源。

Pinterest 的 Terraform 代码分散在多个代码库中，分别由不同团队负责。虽然将这些代码库整合为单一代码库的工作仍在进行中，但在此之前，如果直接授予 CI/CD 系统跨多个代码库和 AWS 账户的系统级权限，会带来显著风险——既可能引发意外的配置错误，也可能增加恶意操作的概率。RPP 正是为此而生：它充当一座桥梁，在底层整合尚未完成时，先确保多代码库环境的安全。

RPP 如何运作：从 PR 触发到双重审核

RPP 在 GitHub 拉取请求（PR）事件触发时启动，以一组集中式的复合 GitHub Actions 形式运行，而非按代码库执行的脚本。它将单个 PR 拆分为针对每个受影响工作区的独立 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 服务账户，后来采用 GCP 工具，将无密钥的 Cloud Build 凭据与只读的“plan”账户以及每个服务专用的“apply”账户配对使用，通过模拟身份机制将每个任务的影响范围限制在单个项目内。Slack 则选择了将状态所有权下放给各个团队，同时强制执行“先规划、后应用”的门控机制，变更必须经过沙箱和开发环境才能进入生产环境。

RPP 的特别之处在于它包含一个明确的后端和 KMS 密钥验证步骤——在承接任何角色之前，将工作区的 Terraform 代码路径与状态文件进行比对。这相当于额外的防护层，补充了类似于 Mercari 和 Slack 所采用的角色映射模型，有助于确保集中式 IaC 管道不会演变为单点故障。