我理解将基础结构部署为代码的目标,并欣赏能够强制执行代码同行评审预部署的好处。从安全角度来看,此技术控制向我保证,对环境所做的更改是经过同行评审的。
但是,具有相关权限(例如具有所有者角色(的人是否仍然可以直接在控制台/云外壳上进行更改?然后,此更改将不会进行同行评审。
只是想检查有什么(如果有的话(控件可以防止这种情况?当然,我知道一种控制是限制项目或组织级别的 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。此外,所有者角色并不是唯一允许创建/更新/删除资源的角色。您必须非常小心分配给用户的角色,以确保他们没有此类权限,并且可能会依赖自定义角色,因为预定义的角色通常过于宽泛。