Pinterest公布了其自主研发的Terraform执行引擎——资源配置器管道（RPP），旨在通过集中式管理保障大规模环境中AWS基础设施的安全。该引擎遵循最小权限原则，并需双重控制审核，对Pinterest至关重要。该系统管理着数千个云资源，包括IAM策略、VPC、负载均衡器、S3存储桶和Kubernetes集群。Pinterest的Terraform代码分散在多个代码库中，目前整合工作正在进行中。若赋予CI/CD系统跨多个代码库和AWS账户进行更改的系统级权限，可能带来风险。RPP旨在充当桥梁，确保多代码库环境的安全，无需等待底层整合完成。
--91likeyou---
执行模型
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）管道不会演变为单点故障。
：
🔥 热词：#Terraform · #AWS · #Pinterest · #如何通过集中式 · #管道在大规模环境中保障 · #基础设施的安全 · #公布了其自主研发的 · #执行引擎