security - 如何通过“所有者”与terraform代码冲突来防止GCP控制台/云外壳程序更改？

什么都不会阻止用户创建/更新/删除资源手动（通过手动我的意思是：通过控制台或云壳）如果他有IAM权限这样做。

在手动更新资源的情况下：如果资源是由Terraform管理的，则运行terraform plan将提醒您已进行了修改。确实，Terraform会看到.tf文件中的资源描述与现实之间的差异 。如果您应用这些更改，它将还原用户手动进行的修改。

进行定期检查以验证是否已对Terraform进行了某些修改（在Terraform管理的资源上），可能是一个不错的主意，以提醒您有人进行了手动操作。

但是，对于新创建的资源（不在Terraform中），除非在创建（terraform import）之后将资源导入Terraform中，否则您将永远不会知道该资源已创建，并且无法跟踪对该资源的任何修改。阻止资源创建的唯一方法是限制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。另外，所有者角色不是唯一允许创建/更新/删除资源的角色。您必须谨慎对待授予用户的角色，以确保他们不会获得此类权限，并且可能依赖自定义角色，因为预定义角色通常太宽泛。