你可以把云基础设施想成一栋不断改造的大楼。不同团队都想自己申请房间、改门锁、接网络；但如果每个人都拿着总钥匙直接施工，一次错误就可能影响整栋楼。Pinterest要解决的正是这类矛盾：让团队继续自助交付云资源，同时把真正有破坏力的执行权限收进一条受控流水线。
据Pinterest Engineering的工程博客，公司为此设计了Resource Provisioner Pipeline（RPP）。它是一套专有的Terraform执行引擎，把分散的基础设施变更集中纳入带安全控制的CI/CD流程。CI/CD即持续集成与持续交付，简单说，就是代码提交后自动完成检查、审批和部署的一套流水线。需要注意，现有信息全部来自Pinterest对RPP第一版的介绍，没有外部实测或独立材料交叉验证。
为什么执行端必须管起来？
基础设施即代码（Infrastructure as Code，IaC）是用配置文件描述服务器、网络和权限，而不是让工程师逐项点击云控制台。这样每次修改都能留下记录，也更容易复查和重复执行。
Pinterest采用的Terraform是常见IaC工具。它会比较配置文件里的目标状态和现实状态，再生成并执行变更计划。问题在于，执行Terraform的身份通常有权创建、修改乃至删除基础设施。配置文件可以由很多人编写，但最后由谁执行、能以什么权限执行，才是安全边界所在。
RPP的核心思路，就是把这一步集中起来。开发团队仍然在自己的代码仓库里维护Terraform配置，但基础设施变更统一交给RPP执行。平台由此可以在同一个入口安排检查、审批和受限身份，而不是把云端权限直接分散给各团队。
多仓库不动，先统一出口
Pinterest的Terraform代码分布在多个代码仓库中，每个仓库由不同团队维护。公司正在推动把这些代码整合进一个mono-repository——也就是集中存放相关代码的统一仓库——但迁移尚未完成。
RPP选择先兼容现状：代码暂时仍然分散，执行入口先集中。这个设计值得关注，因为大型组织很少能一次完成架构重整。与其等所有仓库合并后再建立安全规则，不如先把最关键、权限最大的执行动作收口。
Pinterest称，RPP通过集中式GitHub Actions执行、双重控制和安全的角色链机制设置护栏。GitHub Actions是代码仓库里的自动化工作流；角色链则是在不同受限身份之间逐步授权，避免一个执行身份长期持有过大的权限。这与“最小权限”原则一致：人和程序只获得完成当前任务所需的权限。
不过，供稿在工作流调用处截断，未披露双重控制、角色链和策略检查的具体步骤。因此，这些设计可以说明Pinterest如何划定控制边界，却不足以证明它已经消除了错误配置或越权风险。
规模让平台化变得必要
据Pinterest Engineering介绍，RPP管理着数百个Terraform workspaces，合计管控数万个资源。Workspace可以理解为一组独立维护的基础设施状态。覆盖对象包括IAM角色和访问策略、VPC、Security Groups、Load Balancers、DNS、S3 buckets及Kubernetes clusters，横跨权限、网络、存储和计算。
这也是RPP最有参考价值的地方：它没有取消团队自助，也没有要求先完成所有代码整合，而是把Terraform执行做成统一的平台能力。对大型组织而言，平台化不只是提高部署效率，更是在团队数量和资源规模扩大后，继续守住权限边界的一种办法。
局限与未知
- 公开材料只有Pinterest官方博客这一处信源，文中的安全效果属于公司自述，尚无独立验证。
- “数百个workspaces”和“数万个资源”只有数量级，没有精确数字、统计口径或对应时间点。
- 材料介绍的是RPP第一版且内容截断，无法核查后续流程细节，也不能据此认定所有IaC类型或全部基础设施变更均已纳入RPP。