Google Cloud Resource Manager API - Google Workspace/G Suite 用户自己的组织是否总是列在 organizations.list 中？答案

【问题标题】：Google Cloud Resource Manager API - will a Google Workspace/G Suite user's own organization ALWAYS be listed in organizations.list?Google Cloud Resource Manager API - Google Workspace/G Suite 用户自己的组织是否总是列在 organizations.list 中？
【发布时间】：2021-10-20 21:00:27
【问题描述】：

我正在尝试使用Cloud Resource Manager v1beta1 API 的organizations.list 方法来检索用户的组织，最终目标是找到Google Workspace/G Suite 用户自己的本地租户的directoryCustomerId。它是少数可用于检索此信息的 Google API 之一。

由于此 API 返回组织列表，我假设它们代表用户有权访问的 Google Cloud Platform 组织列表，包括用户本身不属于的租户。

我的问题是，是否可以保证对于任何 Google Workspace/G Suite 用户，此列表将至少包括（并且很可能仅包括）用户自己的 Google Workspace/G Suite 组织，即使该组织不使用除了 Google Workspace/G Suite 之外的任何 Google Cloud 产品（因此用户没有对任何此类产品的特殊访问权限）？

【问题讨论】：

标签： google-cloud-platform google-api google-workspace google-cloud-resource-manager

【解决方案1】：

是的，它保证适用于任何帐户，我已经在 3 个不同的帐户上进行了测试：

常规 gmail（非 G 套件和 GCP 资源）
G 套件帐户（无 GCP 资源）
G 套件（带有 GCP 资源）

只是概述，G-suite 是面向最终用户的一系列 Google 产品，包括 GMail、Google Drive、Google Docs、Hangouts 等。另一方面，谷歌云平台是谷歌向开发者或超级用户提供的一系列服务，以便他们创建和运行自己的应用程序。因此，两者在组织和云 API 方面具有相同的结构。请参阅official documentation 了解更多信息。

【讨论】：

谢谢。所以 1. 对于没有 GCP 资源的常规 Gmail，列表应该是空白的（我的测试似乎就是这种情况）？ 2. 对于大多数 G Suite 用户，我认为该列表应该返回一个组织，如果是这种情况，该组织必须是用户的本地租户吗？ 3. 如果返回很多组织，用户可能是管理员或顾问类型的人，可以访问许多独立的 Google 租户（应该相对较少）？
没错。
谢谢，我将此标记为答案，但在一种情况下，我无法找到使其工作的方法。如果 john.doe@acme2.com 属于一个 G Suite 租户，其主域不是 acme2.com，而是 acme1.com（我事先不知道这个信息），并且 john.doe 也恰好可以访问其他组织的资源，我无法通过查看他的 organizations.list 结果来判断哪个组织是他的本地租户，因为这些实体仅由主域 (displayName) 标识。有什么解决方法吗？再次感谢。
你需要使用projects.getAncestry，这个thread应该会有所帮助。
不幸的是，API 没有帮助，因为我们没有任何项目 ID/范围可以使用。我们的用户只需通过 Google 登录即可登录我们的网络应用程序。我们实际上什么都不想做，对他们的 GCP 信息一无所知。我们只需要他们的 G Suite directoryCustomerId。它只是碰巧organizations.list 是唯一一个 API 在没有任何特殊权限/信息的情况下提供此功能（我们只需要询问 cloudplatformorganizations.readonly 范围），但这仅适用于用户的列表返回单个组织或多个组织但与他的电子邮件域匹配。

【解决方案2】：

organizations.search 需要resourcemanager.organizations.get 权限。

默认情况下，该域的所有用户都被授予组织的Billing Account Creator和Project Creator。这两个角色都包含resourcemanager.organizations.get 权限。因此，默认情况下，用户可以看到自己的组织。

但是，通常的做法是删除这两个默认 IAM 绑定。除非您明确授予他们Organization Viewer 角色或包含上述权限的其他角色，否则用户将无法看到他们自己的组织。

【讨论】：

我引用的API是v1beta1下的organizations.list，而不是v1下的organizations.search。所以organizations.list这里cloud.google.com/resource-manager/reference/rest/v1beta1/…的API文档页面实际上并没有提到角色权限，这是否意味着所有用户都应该有权访问它？谢谢。
你不应该使用旧的v1beta1 API，organizations.search 是v1 等效于organizations.list。
但我们的应用实际上需要能够访问此 API（代表用户）并从登录我们服务的任何 G Suite 用户那里获取组织。根据您提供的信息，我实际上必须使用v1beta1 以避免由于用户的租户管理员撤销这些默认绑定而导致缺少resourcemanager.organizations.get 权限的情况。我似乎找不到任何提到 v1beta1 即将停产或不受支持的消息。是否有理由我不应该使用它，如果是，是否有替代方案来满足我们的需求？谢谢。