FAST项目中的Terraform权限管理最佳实践：解决Pub/Sub与Storage权限问题

在Google Cloud的FAST（Foundation Automation and Secure Terraform）项目实施过程中，我们遇到了一个典型的权限管理问题。当项目配置中包含logSink定义时，使用GitHub Actions运行FAST CICD流程会在plan阶段失败，主要涉及两个关键权限问题：

1. Pub/Sub权限不足：Terraform需要检查Pub/Sub主题的IAM策略，但默认的只读服务账户缺少pubsub.topics.getIamPolicy权限
2. Storage权限问题：系统无法删除Terraform状态文件的锁，因为缺少storage.objects.delete权限

问题根源分析

在FAST架构中，0-bootstrap阶段的服务账户（0r）默认仅具有基本查看权限。当配置中包含Pub/Sub相关的日志接收器(logSink)时，Terraform需要验证和设置相关IAM策略，这需要更高级别的Pub/Sub权限。

值得注意的是，FAST默认配置使用日志桶(log buckets)作为日志接收器目标，因此大多数情况下并不需要额外的Pub/Sub权限。只有当项目需要将安全相关记录传输到外部SIEM系统时，才需要使用Pub/Sub作为接收器目标。

解决方案建议

对于确实需要在bootstrap阶段使用Pub/Sub作为日志接收器目标的特殊情况，我们建议：

1. 最小权限原则：为0r服务账户添加必要的权限，而不是直接授予管理员角色

   • 可以创建自定义角色，仅包含必需的pubsub.topics.getIamPolicy等权限
   • 避免直接授予roles/pubsub.admin这样的宽泛角色

2. 架构设计考虑：

   • 将需要Pub/Sub的日志接收器放在专门的security阶段处理
   • bootstrap阶段专注于组织级别的操作数据收集，使用日志桶作为主要目标

3. Storage权限说明：

   • 由于只读plan阶段设计上不需要锁定状态文件，因此不需要添加storage权限
   • 如果确实需要锁定功能，可以谨慎添加roles/storage.objectUser角色

实施建议

对于需要在bootstrap阶段处理Pub/Sub日志接收器的项目，建议通过以下方式实施：

1. 在organization-iam.tf中为0r服务账户添加必要的最小权限
2. 在stage的README中明确记录这一特殊配置要求
3. 考虑使用本地tfvars文件来管理这些特殊权限配置

安全最佳实践

在实施这些变更时，务必遵循最小权限原则：

1. 仔细评估是否真的需要在bootstrap阶段使用Pub/Sub
2. 如果必须使用，创建仅包含必需权限的自定义角色
3. 定期审计这些特殊权限的使用情况
4. 考虑将安全相关的日志处理放在专门的security阶段

通过这种有节制、有针对性的权限管理方法，可以在满足业务需求的同时，保持FAST项目的安全性和可维护性。