【发布时间】：2022-09-23 03:03:51
【问题描述】：
TL;博士
我们正在寻找一种让服务帐户从多个其他服务帐户继承 BQ 读取权限的方法。模仿只适用于一个。
场景
我们公司遵循data mesh 方法，我们的产品团队负责将他们的数据集成到 BigQuery 中。产品所有者也被认为是数据的所有者。因此，由产品所有者决定授予谁访问数据的权限。
在分析团队中，我们通常在 BigQuery 查询中组合来自多个源系统的数据。我们的 ETL 进程在 kubernetes 集群上运行，每个进程都使用一个单独的服务帐户。这为我们提供了细粒度的访问控制，因为每个进程对数据的访问仅限于他们真正需要的那些对象。这种设计还有助于我们进行调试和成本控制。另一方面，这会导致源端出现问题：
问题
每次我们设计一个新的流程时，我们都需要向数据所有者索取许可。他们已经同意我们的健康级别的产品团队/系统可以访问他们的数据，因此这个授权过程非常繁琐，并且使数据所有者感到困惑。
我们希望每个拥有必要 BQ 读取权限的源对象只有一个“代理”服务帐户。然后将设置进程的服务帐户以从它们需要访问的那些 BQ 源的代理服务帐户继承权限。
使用impersonation 仅在它只是一个源系统时才有帮助，但我们的查询经常使用多个源系统。
使用 Google 网上论坛无济于事
我们讨论了一个解决方案，在该解决方案中，我们为要读取的每个源系统设置了一个 google 组。 BigQuery Data Reader 角色将分配给该组。反过来，需要这些权限的服务帐户将被添加到该组中。但是，公司政策不允许将服务帐户添加到 google 组。此外，我们的产品团队不能自己管理（创建）google 组，因此这种方法缺乏灵活性。
实施粗粒度方法
一种方法是使用更粗粒度的访问控制，即仅对所有 ETL 流程使用一个服务帐户。我们可以将进程名称作为标签添加到查询中，以涵盖调试和成本控制部分。但是，如果可能的话，我们更喜欢一种方法，其中进程只能访问尽可能少的数据对象。
标签： google-cloud-platform google-bigquery google-cloud-iam