介绍身份和访问管理(IAM)的任何人开始与 GCP，甚至有经验的专业人士谁正在寻找一个结构化的概述

每天‬分享‬最新‬软件‬开发‬，Devops，敏捷‬，测试‬以及‬项目‬管理‬最新‬，最热门‬的‬文章‬，每天‬花‬3分钟‬学习‬何乐而不为‬，希望‬大家‬点赞‬，加‬关注‬，你的‬支持‬是我‬最大‬的‬动力‬。

身份和访问管理(Identity and access management，IAM)是像 GCP 这样的云基础设施环境中最重要的安全控制之一。由于执行的几乎每个操作都是 API 调用(包括供应、取消供应和操纵资源) ，恶意参与者进入您的环境所需要的只是对错误身份的权限的错误绑定，或者是一个受损的身份。

因此，关键是要密切注意授予对 GCP 组织中资源的访问权限，并确保只提供执行业务功能所需的最小数量的权限。换句话说，您需要在任何时候都为所有身份(包括人类和服务)维护最小特权。

本文将回顾在 GCP 中管理资源权限的主要机制。这是一个伟大的介绍任何人开始与 GCP，甚至有经验的专业人士谁正在寻找一个结构化的概述。

GCP 采用基于角色的访问控制(RBAC)机制进行权限分配。RBAC 意味着任何权限分配都基于标识应该执行的功能。实现使用称为“ Roles”的权限文档，并定义标识(或“主体”)、“角色”和“范围”之间的连接ーー即应用权限的资源层次结构的级别。

下图说明了与 GCPIAM 相关的对象，以及它们如何相互映射，以便为资源(或资源)的一组权限分配标识。我们将探讨所有这些术语。

图1-GCP 中与 IAM 相关的对象说明

由于范围是 GCP IAM 范式中的一个非常重要的概念，因此适当地构造组织中的资源是非常重要的。出于这个原因，我们将从讨论如何构建资源开始。

资源结构

当您开始使用 GCP 时，将为您创建一个“组织”资源:

当使用 Google Workspace 或 Cloud Identity 帐户的用户创建 Google Cloud Project 时，将自动为他们提供一个 Organization 资源。

组织资源代表拥有它的公司，是在层次结构中结构化在一起的文件夹、项目和资源的容器; 这种结构允许管理各种策略，而 IAM 是最重要的一种。

图2 显示了 GCP Organization 资源中的资源层次结构。

图2-GCP 中的资源层次，来源:Google 谷歌

项目是原子容器，用于管理与应用程序的相同部署(例如，开发/测试/暂存/生产)相关的资源ーー例如，< APP_NAME >-development、 < APP_NAME >-暂存或 < APP_NAME >-生产。它也是资源的主要计费单元，因为它与计费帐户有1:1的关系。如果你熟悉 Azure，你会看到这两个功能使得项目相当于 Azure 的资源组(意味着包含与同一应用相关的资源)和 Azure 的订阅(主要的计费单元)。

项目可以直接位于组织资源或文件夹中。

文件夹应该与您的组织结构相对应，以便为组织中的项目提供结构。它们支持嵌套，因此文件夹中可能有子文件夹。

在 IAM 的上下文中，正确地构造资源非常重要，因为可以授予特定资源的权限，或者授予任何级别(组织、文件夹或项目)的资源容器的权限(我们将在后面演示这个概念)。如果您将资源结构正确地与业务对应起来，那么提供正确的访问就容易得多。

下一节将回顾可能被授予访问权限的各种身份。

身份

Google Cloud Identity 是一个“身份即服务(Identity as a Service，IDaaS)解决方案，集中管理用户和组”。它基本上是一个身份提供程序(Identity Provider，IdP) ，您可以在其中创建用户和组对象，并管理诸如安全因素(security factor，MFA)和应用程序访问等参数。为了简单起见，我们将这个服务简称为 Google Cloud Identity，但是请记住，您可能知道它是 Google Workspace。

在 Google Cloud Identity 中，您管理用户和组，并且还可以通过使用 Domain 标识来引用 Google Cloud Identity 实例中的整个用户名册。

使用者

在 GoogleWorkspace 中，您为组织管理用户对象。用户通过电子邮件进行唯一标识，并被划分为组织单元(OU) ，这对于设置策略(如 MFA 和应用程序访问)很有用。然而，OU 与管理 IAM 对 Google 资源的访问并不相关。

图3-驻留在 OU 中的 Google Cloud Identity 用户

谷歌群组

管理用户访问 GCP 资源的相关机制是 GoogleGroup。由于 Google Group 传统上是作为邮件分发列表的解决方案(并且仍然经常用于此目的)开始的，因此它们也通过电子邮件帐户进行唯一标识。出于我们的目的，你可以使用这个唯一标识符来为你的云资源分配权限(稍后我们会看到)。当您这样做时，您将提供对属于该 Google Group 的所有身份的访问。更好的做法是提供对 Google Group 的访问，而不是分别管理每个用户的权限。

请注意，Google Group 可能是嵌套的，并且包含其他 Google Group (它将继承分配给该组的权限) ，而 Google Group 可能包含服务帐户(我们将在下一节中讨论)。

图4-Google Group

谷歌群组与组织结构群组有很大的不同，而后者是严格的，一个用户只能属于其中的一个(因为它们意味着与人力资源部门定义的群组相对应) ，一个用户可能同时属于几个群组(从而获得几组权限或成为几个通讯组列表的成员)。此外，Google Group 可能包含来自组织外部的身份，因为它们不像 OU 那样必须遵循组织的结构。记住这一点很重要，因为分配给组的权限也将适用于这些用户，根据定义，从技术和法律角度来管理这些用户的风险更大。

域名

最后，在 GCPWorkspace 上下文中必须熟悉的对象是域。

每个 Google 云身份都有一个主域(以“@company _ name. com”的形式) ; 这个主域可以用来为 Google 云身份实例中管理的所有用户分配云资源的权限。

这里有两点需要注意: 首先，为主域分配权限将允许访问在云身份实例中管理的所有用户，但不允许访问在那里管理的 Google Group。这背后的逻辑很清楚，因为允许访问谷歌群组中的身份也可能允许访问外部身份，这将是一个巨大的安全风险。

其次，一个 Cloud Identity 实例也可能有辅助域(实际上，多达599个辅助域!).出于这个原因，我们强调这样一个事实，即主域是计数的域，而不是用户的实际域(这是不相关的)。例如，如果你的云身份环境中有一个辅助域名(例如，“@second. com”) ，而你的主域名是“@basic. com”，那么指定访问“@basic. com”实际上会为所有在云身份实例中管理的后缀为“@second. com”的用户提供访问权限。它们的域与分配给它们的权限的域不同，这一事实是不相关的。

现在，让我们继续讨论 GCP 本身管理的身份。

服务帐户

服务帐户是一种代理身份，在 GCP 中起着非常重要的作用。

代理标识意味着其他实体(如资源)可以使用它来访问其他资源。(比如 AWS 里的角色?)

一个服务帐户可能被一个 Google Cloud Identity 用户、一个个人 Gmail 帐户、另一个服务帐户(即使它位于不同的组织)、一个 Google Group，以及基本上任何可能被分配权限的身份使用。

服务帐户如何运作

使用服务帐户可以通过以下三种方式之一:

服务帐户可以是依附于某种资源, 然后，当资源运行工作负载时，该资源可以使用分配给服务帐户的权限; 例如，计算实例附加了一个服务帐户，当代码在其上运行时，它将能够访问分配给服务帐户的权限。为了这样做，许可。 必须可用于标识供应服务帐户所附加的资源(在我们的示例中是计算实例)可以使用该操作直接模拟服务帐户. 它允许执行模拟的标识能够使用分配给服务帐户的权限最后，服务帐户支持 创建临时的凭证. 然后可以在进行 API 调用时使用它来利用分配给服务帐户的权限服务帐户类型

服务帐户有三种主要类型:

用户管理: 由 GCP 项目管理人员创建和管理的服务帐户默认值: 由 Google 创建并可能由项目管理员管理的服务帐户。建议将它们作为默认(因此命名为)服务帐户附加到某种类型的资源。熟悉这种机制至关重要，因为有时这些默认服务帐户被授予非常宽松的权限，比如计算机引擎默认服务帐户，默认情况下，它被授予项目的“编辑器”基本角色(我们很快就会看到，这是非常宽松的)Google-managed: 谷歌管理: 这些是谷歌在启用项目中需要访问云资源的相关服务时创建的服务帐户。默认情况下，这些服务帐户被授予某些角色(项目管理员可以删除这些角色，但这不是推荐的做法)。我们在一篇文章中回顾了这个主题以及与之相关的一些风险recent blog post 最近的博客文章.小心静态凭证

服务帐户的另一个重要特性是为它们生成密钥对的能力。密钥对基本上是一组字符串，它们支持将身份验证作为服务帐户，一旦这样做了，您就可以代表服务帐户执行操作，并且可以完全访问服务帐户拥有的所有权限。

如果管理不当，这当然是一个巨大的安全风险，有些人可能会认为您应该完全避免使用它们。假设这些密钥落入坏人之手ーー例如，如果它们不适当地存储在公共资源中，比如存储桶、公共文档、公共代码存储库、许多人都可以访问的环境变量等等。一个恶意的行为者可能在你不知情的情况下持有并使用它们。

因此，您必须尽可能避免对服务帐户使用密钥对。例如，如果工作负载需要访问权限，将服务帐户附加到工作负载正在运行的资源(云功能或计算实例)比使用密钥对、将其存储在某个地方并让工作负载使用它进行身份验证要安全得多(即使它存储安全，也不能保证不泄漏)。此外，当开发人员可以使用具有强制 MFA 的 Google 帐户进行身份验证时，不应该在本地使用密钥对来使用 GCP CLI。

也许最糟糕的事情，你可以做一个密钥对是提供给第三方，请求它访问资源在您的帐户。如果只有自己的员工使用静态凭证，那么很难保证其安全性ーー确保这些凭证在第三方手中是安全的几乎是不可能的。

最后，如果您实际上处于必须使用密钥对的位置，请确保正确地存储和定期轮换密钥对(至少每90天一次)。

图5-在 Google 控制台中为服务帐户生成的密钥对

图6-密钥对的文本表示(编校)

特殊标识符

我们要注意的最后一种标识类型是两个特殊的标识符: allUsers 和 allAuthenticatedUsers。

他们分别允许访问“任何在互联网上的人”和“所有服务帐户和所有在互联网上经过谷歌帐户认证的用户”因此，基本上，在权限分配中使用它们中的任何一个都会使该分配对应用它的资源公开。最好在这里举个例子。

许多人认为这些标识符只与 Google Cloud Identity 实例中的用户有关，当然事实并非如此。所以，小心！

角色

第三个，可能也是最容易理解的对象是“角色”。

“角色”只是列出权限的文档。在下一节中，我们将看到绑定是如何创建的，权限分配是如何实际创建的，但是首先让我们回顾一下角色的三种类型。

基本的

这些是由 Google 创建和管理的遗留角色(它们也可以被称为“原始”角色)。它们是非常宽容的，并且对所有资源类型都是通用的(因此，正如您可能预期的那样，它们拥有大量的权限)。

有三个基本角色: 查看器、编辑器和所有者。

在使用它们时，你必须非常小心ーー最好避免把它们全部放在一起使用。正如我们前面提到的，您可能还希望在默认授予它们的情况下替换它们，例如对于计算引擎的默认服务帐户，该帐户在启用计算服务的项目上被授予编辑者角色。

不要将这些角色授予 Google Cloud Identity 之外的用户或 GCP 组织之外的服务帐户。

这些角色提供的一些权限也存在额外的风险ーー我们将在下一篇文章中更详细地探讨这个主题。敬请期待！

预先定义好的

与基本角色一样，预定义角色也是由 Google 创建和管理的。然而，它们更加细粒度化，通常是为特定类型的资源和特定的工作职责/功能定义的。例如，预定义的“角色: 存储对象查看器”允许查看存储桶中的对象。

尽管它们的风险比 Basic 角色小，因为它们包含的权限要少得多，但是在使用它们时仍然应该注意，因为可以将它们应用于非常广泛的范围(项目、文件夹或组织) ，这样做将为驻留在该范围下的所有资源提供权限。

Custom

最后，您可以创建和管理自己的自定义角色，这些角色是您根据特定函数定制的权限列表。

使用这些角色是一个挑战，因为您必须非常熟悉您的身份需要执行的活动。但是，如果正确配置它们，它们是实现最小特权的最佳方法。

放在一起: 创建绑定

为了把所有这些放在一起，我们现在将使用我们回顾过的概念ーー具有不同作用域的标识、角色和资源结构ーー并查看如何实际授予权限。

要授予权限，您需要创建所谓的“绑定”ーー一个对象，该对象在某个特定范围的某个标识(我们上面映射的任何一个标识)之间建立连接ーー一个资源或资源容器。

这些绑定聚集在一个名为 IAM Policy 的文档中，该文档存在于每个作用域中。绑定包括可以授予角色的角色和成员(身份)。它还可以有选择地包含限制绑定应用的时间和地点的条件。图7显示了 IAM 策略的一个示例:

图7-IAM 策略文档示例，来源:Google 谷歌

可以为外部用户(例如个人 Gmail 帐户、第三方服务帐户等等)创建绑定，就像为来自您的 Google Cloud Identity 实例或您组织中的服务帐户的用户创建绑定一样容易。这方面的一个例子可以在图8中看到。所以，请密切关注这一点！此外，很难通过访问组织中的资源来跟踪外部身份，因为 GCP 中没有特定的本机工具将所有资源集中在一个显示器中。

图8-为外部身份(Gmail 帐户)创建绑定与为内部身份创建绑定一样容易

最后，重要的是要记住，如上所述，授予作用域上的角色是继承给它下面的作用域ーー容器和资源。图9展示了这一点:

图9-继承原则的说明

在关系图中，ComputeAdmin 角色应用于设置它的作用域中的所有计算资源。Owner 角色(基本角色)同时适用于计算和云函数资源。

这也可以在每个作用域的 IAM 刀片中看到，您可以在其中找到所有绑定的列表，这些绑定或者直接为其制作，或者由更广泛作用域的成员继承。在图10中，你可以看到一个 GCP 项目的可视化示例: 除了角色和主体，还有一个“继承”列，清楚地说明权限是由于直接绑定，还是从项目所属的范围继承的(在这个特定示例中，从项目所属的组织资源的绑定)。

图10-IAM 刀片显示 GCP 项目的 IAM 策略

总结

我们希望这篇评论能够帮助您清楚地了解 GCP 中的 RBAC 范式。