为什么 gcp IAM 权限默认如此开放,以及限制 GCP 存储桶访问的良好常见做法是什么?

为什么 gcp IAM 权限默认如此开放,以及限制 GCP 存储桶访问的良好常见做法是什么?

我有一个由其他人通过 GCP 控制台设置的 GCP 云,具有默认权限。其中有一些存储桶、计算引擎虚拟机和云运行服务。我正在将其移动到 Terraform 部署,并希望收紧权限。我看到默认情况下,有许多服务帐户在项目级别具有权限(服务代理角色绑定),这意味着它们对项目中的所有内容都具有这些权限。例如,角色 Compute Engine Service Agent具有

storage.objects.create
storage.objects.get
storage.objects.list
storage.objects.update 

并且该Cloud Run Service Agent角色

storage.managedFolders.get
storage.managedFolders.list
storage.objects.get
storage.objects.list 

如果我理解正确,这意味着在项目级别具有这些角色的任何用户/服务帐户(所有默认服务帐户都是这种情况)都可以访问(并且在 的情况下写入Compute Engine Service Account)项目中任何存储桶中的任何文件。我正在存储桶级别使用特定绑定制定自己的策略(同时使用统一访问和公共访问预防),因此我可以控制哪些角色可以访问存储桶及其内容,但似乎这些项目级别的权限完全抵消了我在资源(存储桶)级别为收紧权限所做的任何努力。

谷歌似乎坚持最小特权原则,但随后默认为服务代理角色授予这些权限。所以我的问题是 2 个:

我真的必须将所有这些默认服务代理角色(有很多,每个服务至少有一个角色和一个默认服务帐户)转换为自定义角色,从默认服务帐户中删除所有默认服务代理角色的绑定,然后将我的自定义角色分配给它们,这样他们就无权访问所有 gcp 存储桶?这似乎是一项艰巨的工作,而且由于我错过了一项特权,因此很有可能出现错误。我无法想象谷歌的意图是让我抛弃他们所有的默认服务代理角色和服务帐户,只是为了遵循 GCP 存储桶上的最小特权原则。

如果我在这里遗漏了一些东西(我希望如此),那么我如何确保我可以将具有存储桶上的 IAM 权限的角色列入白名单,而不必担心其他默认权限和角色具有项目级存储权限?

相关内容