如何通过"Owners"与地形代码冲突来防止 GCP 控制台/云外壳更改?



我理解将基础结构部署为代码的目标,并欣赏能够强制执行代码同行评审预部署的好处。从安全角度来看,此技术控制向我保证,对环境所做的更改是经过同行评审的。

但是,具有相关权限(例如具有所有者角色(的人是否仍然可以直接在控制台/云外壳上进行更改?然后,此更改将不会进行同行评审。

只是想检查有什么(如果有的话(控件可以防止这种情况?当然,我知道一种控制是限制项目或组织级别的 IAM 权限,以防止进行更改,因为从那时起只有 terraform 服务帐户可以进行更改,但我想了解是否有任何其他控制。

没有什么可以阻止用户手动创建/更新/删除资源(我的意思是手动:通过控制台或云外壳(,如果他有 执行此操作的 IAM 权限。

手动资源更新的情况下:如果资源由 Terraform 管理,运行terraform plan将提醒您已进行修改。事实上,Terraform将看到资源描述之间的差异.tf文件和现实。如果应用这些更改,它将还原用户手动进行的修改。

运行定期检查以验证是否已从 Terraform (在 Terraform 管理的资源上(进行了某些修改可能是一个 提醒您有人手动执行某些操作的好主意。

但是对于新创建的资源(在 Terraform 之外(,除非资源在创建后导入到 Terraform 中(terraform import(, 你永远不会知道此资源已创建,并且无法跟踪对该资源的任何修改。 防止创建资源的唯一方法是限制 IAM 权限。例如,如果没有人(除非 Terraform 服务帐户(具有权限storage.buckets.create,则没有人(Terraform 服务帐户除外(能够创建存储桶。这同样适用于资源更新。

如果您希望所有资源都由 Terraform 管理,请删除除 Terraform 服务账户之外的所有用户的创建/更新 IAM 权限。但请注意:

  • 您无法使用 Terraform 创建/更新所有 GCP 资源。即使 Terraform 提供商发展迅速,新的 GCP 产品与其在 Terraform GCP 提供商中的实现之间也总会有一些延迟。前段时间,我记得自己在Terraform中等待Cloud Composer资源, 它出现在 2018/09/17 的 1.18.0 版本中,尽管 Cloud Composer 自 2018/05/01 起可用。如果我选择仅使用 Terraform 创建资源,那么我应该等待 4 个月才能开始使用 Cloud Composer(这是一个例子(
  • 您有时可能希望在 Terraform 之外创建资源,例如用于测试目的。如果强制使用 Terraform 创建/更新整个组织中的所有资源,则无法做到这一点。想想那些想要临时创建一些资源来进行一些测试的非技术用户:他们可能不会学习如何使用 Terraform,所以他们要么放弃,要么要求某人为他们创建资源。随着用户数量的增加,这应该变得很麻烦
  • 荒谬的推理:你想使用Terraform管理所有可用的资源吗?如果是这样,那么您可能还需要使用 Terraform 管理存储对象,因为有一个 Terraform 资源google_storage_bucket_object。除了一些非常特殊的情况,你不想用Terraform管理这类资源(在存储对象的情况下,想想大文件(

总之,使用 Terraform 管理整个组织中的所有资源并仅限制 Terraform 服务帐户创建/更新/删除资源绝对是一个目标,应该尽可能多地完成,但实际上,这并不总是完全可能的。关键资源必须受到保护,因此必须限制用于更新/删除它们的 IAM。此外,所有者角色并不是唯一允许创建/更新/删除资源的角色。您必须非常小心分配给用户的角色,以确保他们没有此类权限,并且可能会依赖自定义角色,因为预定义的角色通常过于宽泛。

相关内容

  • 没有找到相关文章

最新更新