如何不使用Terraform Cloud实现远程Terraform工作空间的访问管控

开源版本Terraform确实未内置工作空间级的访问权限控制能力，该能力属于Terraform Cloud/Enterprise的商业特性，你可以通过以下三类无需采购商业版的方案实现需求：

方案1：云厂商对象存储IAM细粒度管控（落地成本最低） #

绝大多数团队使用的remote backend都基于对象存储（S3/OSS/GCS等）加分布式锁实现，直接复用云厂商IAM能力即可实现权限隔离：

• 将不同工作空间的状态文件存储在对象存储的独立路径下，路径示例：
  • s3://terraform-state-bucket/workspaces/app-dev/terraform.tfstate
  • s3://terraform-state-bucket/workspaces/app-int/terraform.tfstate
  • s3://terraform-state-bucket/workspaces/app-prod/terraform.tfstate
• 为不同身份配置对应路径的读写权限：
  • 为当前团队的IAM用户组配置app-dev路径的读写权限，其余团队无该路径的访问权限
  • 仅为CI服务的专用IAM角色配置app-int、app-prod路径的读写权限，所有人类用户仅配置这两个路径的只读审计权限，无写入权限
• 配套的分布式锁组件（如DynamoDB）可同步配置item级权限，匹配对应工作空间的访问规则
• 优势：无额外服务部署成本，复用云厂商成熟的IAM安全能力，配置简单，合规性可满足大多数企业要求
• 适用场景：使用云厂商对象存储作为remote backend的团队

方案2：自托管HTTP Backend服务（自主可控性最高） #

如果是私有部署场景，不希望绑定云厂商能力，可以自行部署兼容Terraform HTTP Backend协议的状态管理服务，在服务层做权限拦截：

• 所有访问状态的请求必须携带身份凭证（API密钥、OIDC Token等），服务端校验凭证后，判断请求身份是否具备对应工作空间的操作权限
• 可自定义权限粒度：支持读写权限分离、按团队/服务账号分配权限，还可扩展审计日志、状态版本回溯、变更校验等附加能力
• 优势：完全自主可控，可根据团队需求定制功能，不绑定任何云服务
• 适用场景：具备一定研发能力、对数据主权要求高的私有部署团队

方案3：代码仓库权限前置管控（轻量无额外改造） #

如果团队规模较小，且已经实现Terraform变更全流程通过CI/CD执行，可以通过代码仓库权限做前置管控，无需修改现有backend配置：

• 将不同工作空间的Terraform代码拆分到独立的仓库目录或独立仓库，为不同身份配置对应目录/仓库的访问权限
  • app-dev目录对当前团队开放编辑权限，其余团队无权限
  • app-int、app-prod目录仅允许CI服务和少数运维人员有编辑权限
• 所有Terraform apply操作仅允许在CI流水线中执行，禁止人类用户本地执行操作，流水线根据触发的代码路径自动对应操作对应工作空间
• 优势：无额外基础设施部署，复用现有代码仓库的权限体系，改造量极小
• 适用场景：已经落地GitOps流程、Terraform变更全链路CI/CD化的中小团队

内容的提问来源于stack exchange，提问作者spierce7