Pinterest 公布自研 Terraform 执行引擎——资源配置器管道（RPP），以集中式复合 GitHub Actions、链式角色承接与 AI 辅助扫描为三大支柱，在跨多个代码库、管理数千云资源的 AWS 环境中守住最小权限与双重控制。这也是 AI 辅助扫描在基础设施即代码安全链路中的一次完整落地。
Pinterest 的 Terraform 代码分散在多个代码库中，每个由不同团队负责，整合为单体代码库的工作仍在进行。如果直接给 CI/CD 系统跨代码库、跨 AWS 账户的系统级权限，代价是巨大的——"这会增加意外配置错误和恶意操作的发生概率。"原文没有回避风险。
RPP 的定位，是一座桥。
在底层整合完成之前，它先让多代码库环境安全起来：所有工作区统一由一套集中式执行引擎调度，覆盖 IAM 策略、VPC、负载均衡器、S3 存储桶与 Kubernetes 集群等数千个云资源。
RPP 管理"众多 Terraform 工作区"，每个工作区对应独立的 S3 后端与 KMS 密钥。数据来自 Pinterest 官方工程实践说明。
RPP 不是按代码库执行的脚本，而是一组集中式复合 GitHub Actions。单个拉取请求会被拆分为针对每个受影响工作区的独立 plan/apply，执行过程采用链式角色模型——
读法：从左到右为一次 PR 的完整执行链；角色权限逐步收窄，任何一步都只拥有完成当前动作所需的最小权限。
第一步，工作流承担中央 RPPActionsRole，借助 OIDC 令牌验证，该角色仅限于预先授权的 GitHub 工作流；第二步，读取"权威数据源"文件——每个工作区与允许访问的代码库、工作目录、所属团队以及 Execution IAM 角色的映射。
容易被忽略的是第三步。在缩小作用域之前，RPP 会检查 Terraform 代码路径是否与工作区专属的 S3 后端与 KMS 密钥匹配。开发人员可能无意中把一个工作区的目录链接到另一个工作区的状态文件——这步检查专门拦截此类错误。只有检查通过后，管道才会承接工作区专属团队角色，运行 terraform fmt 与 plan。
所有代码变更需经所属代码库中已授权的审阅者签批。
plan 完成后，需一条明确的人工评论才触发 apply。
plan 与 apply 由此成为两次相互独立、可审计的操作——任何一步都无法独自触碰真实 AWS 账户。
集中式管道带来的红利不止权限控制。因为所有检查都挂载在同一执行引擎上，系统性问题只需在一个地方修复——比如 CI 运行器 shell 存在漏洞，不必在数百个独立代码库中分别打补丁。
AI 辅助扫描也因此有了一个必经的挂载点。
保障集中式基础设施即代码（IaC）管道的安全是公认难题，Pinterest 不是唯一面对它的公司。Mercari 与 Slack 给出了不同的答案。
三者并非互斥方案：RPP 的差异化在于多出的那一步"承接角色之前的后端校验"，它补充了前两家未覆盖的状态一致性风险。
RPP 的特殊之处，正是那一层"承接角色之前的后端校验"。
RPP 是私有系统，没有开源。但 Pinterest 留下了一份可复用的设计模式——"工作区-路径-角色"映射。
单一文件描述每个工作区允许访问的代码库、工作目录、所属团队与 Execution IAM 角色。
承接任何角色之前，先把代码路径与专属 S3 后端、KMS 密钥比对。
每个工作区只用专属团队角色执行 plan/apply，全程无全局高权限。
团队可以在不迁移单体代码库的前提下，用这套模式在 PR 驱动的 Terraform 管道中强制最小权限。
Pinterest 的 RPP 没有发明新的权限模型，也远非银弹——它是私有系统，依赖 GitHub Actions 生态。但它做对了一件事：把校验、AI 扫描与最小权限写进每次 plan/apply 的必经路径。当防护变成管道的默认组件，基础设施安全的竞争焦点，将从"谁的权限表更干净"转向"谁把安全内嵌得更深"。