GCP 默认服务帐号最佳安全做法答案

【问题标题】：GCP default service accounts best security practicesGCP 默认服务帐号最佳安全做法
【发布时间】：2022-01-27 00:31:07
【问题描述】：

所以，我们有一个“Compute Engine 默认服务帐户”，一切都清楚了：

这是一个具有过多权限的旧帐户
它曾经受到分配给每个 GCE 实例或实例组的“范围”的限制
建议删除此帐号，并以最小权限原则为每个服务使用自定义服务帐号。

文档中提到的第二个“默认服务帐户”是“App Engine 默认服务帐户”。据推测，它已分配给 App Engine 实例，而且它也是一个遗留问题，需要与 Compute Engine 默认服务帐户类似地对待。对吧？
那么“Google APIs 服务代理”呢？它具有“编辑”角色。据我了解，此帐户由 GCP 内部使用，我作为用户创建的任何自定义资源都不能访问该帐户。这是否意味着没有理由为了遵守最佳安全实践而减少其权限？

【问题讨论】：

1/2) 征求意见是有问题的。首先，这与 Stack Overflow 无关。其次，答案会根据回答者的经验和观点而有所不同。相反，创建一个详细说明您要解决的问题的问题。例如，您希望保护只需要访问 Cloud Storage 的 Compute Engine 实例。默认服务帐户不是旧的，我不建议删除它们。相反，创建一个仅具有所需权限的服务帐户，仅此而已。将该服务帐户分配给需要这些权限的服务。
2/2) 实现安全性需要权衡取舍。强大的安全性需要专业知识、明确定义的场景，并且更难使用。弱安全性使系统更容易受到攻击，但更容易使用。也有成本权衡。您必须设计和实施所需的安全级别。这需要投资以了解什么是安全性以及如何实施它。

标签： google-cloud-platform service-accounts google-iam

【解决方案1】：

您不必删除您的default service account，但在某些时候，最好创建具有工作所需minimum permissions 的帐户，并根据您的需要优化权限，而不是使用默认权限。

您可以完全控制此帐户，因此您可以随时更改其权限，甚至删除它：

Google 会创建 Compute Engine 默认服务帐号并将其自动添加到您的项目中，但您可以完全控制该帐号。

Compute Engine 默认服务帐号是使用 IAM 基本编辑者角色创建的，但您可以修改服务帐号的角色以控制服务帐号对 Google API 的访问。

您可以从您的项目中禁用或删除此服务帐户，但这样做可能会导致任何依赖服务帐户凭据的应用程序失败

如果出现问题，您可以recover the account up to 90 days。

也建议使用not to use service accounts during development，因为这可能会在未来造成安全风险。

Google APIs 服务代理

此服务帐号专门设计用于代表您运行内部 Google 流程。该帐号归 Google 所有，未列在 Cloud Console 的“服务帐号”部分中

另外：

某些资源依赖于该服务帐号和授予该服务帐号的默认编辑者权限。例如，托管实例组和自动扩展使用此账户的凭据来创建、删除和管理实例。如果您撤消服务帐号的权限，或以不授予创建实例权限的方式修改权限，这将导致托管实例组和自动缩放停止工作。

由于这些原因，您不应修改此服务帐号的角色，除非角色建议明确建议您修改它们。

话虽如此，我们可以得出结论，删除默认服务帐户或 Google API 服务代理是有风险的，需要大量准备工作（尤其是后者）。

查看best practices documentation 描述管理服务帐户时推荐和不推荐的内容。

你也可以看看securing them against any expoitation和changing the service account and access scope for an instances。

【讨论】：

访问范围是一项旧功能：cloud.google.com/compute/docs/access/…

【解决方案2】：

当您谈论安全性时，您尤其会谈论风险。那么，默认服务帐号有哪些风险。

如果您在 GCE 或 Cloud Run（Compute Engine 默认服务帐号）上使用它们，则您拥有超过权限。如果您的环境是安全的，则风险很低（尤其是在 Cloud Run 上）。在 GCE 上风险更高，因为您必须保持最新的 VM 并控制防火墙规则才能访问您的 VM。

注意：默认情况下，Google Cloud 创建一个 VPC，防火墙规则在端口 22、RDP 和 ICMP 上向 0.0.0.0/0 开放。这也是一个默认修复的安全问题。

App Engine 和 Cloud Functions 默认使用 App Engine 默认服务帐号。与 Cloud Run 相同，风险可以认为是低的。

另一个重要方面是在这些默认服务帐户上生成服务帐户密钥文件的能力。服务帐户密钥文件是简单的 JSON 文件，其中包含一个私钥。这一次风险非常高，因为少数开发人员非常关心该文件的安全性。

注意：在以前的公司中，我们遇到的唯一安全问题来自这些文件，尤其是具有编辑角色的服务帐户

大多数时候，用户不需要服务帐户密钥文件来开发（我在 Medium 上写了很多文章）

有两种方法可以降低这些风险。

执行 IaC（基础架构即代码，使用类似 teraform 的产品）来创建和部署您的项目，并执行您在公司中定义的所有最佳安全实践（没有默认防火墙规则的 VPC，服务帐户没有编辑角色， ...)
使用organisation policies，尤其是这个“禁用服务帐户密钥创建”来防止创建服务帐户密钥，而这个“禁用默认服务帐户的自动 IAM 授权”来防止默认服务帐户的编辑角色。

删除不是解决方案，但对风险的充分了解、团队中良好的安全文化和一些组织政策是关键。

【讨论】：