【问题标题】:How can I grant a Cloud Run service access to service account's credentials without the key file?如何在没有密钥文件的情况下授予 Cloud Run 服务访问服务帐号凭据的权限?
【发布时间】:2021-02-15 20:50:02
【问题描述】:

我正在开发一个 Cloud Run 服务,该服务使用服务帐户的机密文件和以下 python 3 代码访问不同的 Google API:

from google.oauth2 import service_account
credentials = service_account.Credentials.from_service_account_file(SECRETS_FILE_PATH, scopes=SCOPES)

为了部署它,我在构建/部署过程中上传了机密文件(通过gcloud builds submitgcloud run deploy 命令)。

如何避免像这样上传机密文件?

编辑 1:

我认为重要的是要注意我需要模拟来自 GSuite/Workspace 的用户帐户(具有域范围的委派)。我处理这个问题的方法是使用上述凭据,然后:

delegated_credentials = credentials.with_subject(USER_EMAIL)

【问题讨论】:

    标签: python authentication google-cloud-platform google-cloud-run


    【解决方案1】:

    我找到了解决问题的一种方法。

    首先,按照guillaume blaquiere answer的建议,我使用了google.auth ADC机制:

    import google.auth
    credentials, project_id = google.auth.default(scopes=SCOPES)
    

    但是,由于我需要模拟 GSuite(现为 Workspace)的帐户,因此此方法是不够的,因为从此方法生成的 credentials 对象没有 with_subject 属性。这让我看到了这篇类似的帖子和特定的answer,它可以将google.auth.credentials 转换为service_account.Credentials.from_service_account_file 返回的Credential 对象。他的解决方案存在一个问题,因为似乎缺少身份验证范围。

    我所要做的就是将https://www.googleapis.com/auth/cloud-platform 范围添加到以下位置:

    1. 代码中的 SCOPES 变量
    2. Google 管理员 > 安全 > API 控制 > 为我部署的服务帐户设置客户端 ID 和范围
    3. 在我的项目的 OAuth 同意屏幕上

    之后,我的 Cloud Run 可以访问能够在不使用密钥文件的情况下模拟用户帐户的凭据。

    【讨论】:

      【解决方案2】:

      为了提高安全性,最好的方法是永远不要在本地或 GCP 上使用服务帐户密钥文件 (I wrote an article on this)。为了实现这一点,Google Cloud 服务有一个自动加载的服务帐户,可以是默认帐户,也可以是自定义帐户。

      Cloud Run 上,默认服务帐号是 Compute Engine 默认服务帐号(我建议你永远不要使用它,它在项目中具有编辑角色,它太宽了!),或者您可以指定服务帐号来使用(--service-account=参数)

      然后,在您的代码中,只需使用 ADC 机制(应用程序默认凭据)来获取您的凭据,就像在 Python 中这样

      import google.auth
      credentials, project_id = google.auth.default(scopes=SCOPES)
      

      【讨论】:

      • 感谢您的信息!我有一个关于这种方法的问题:在我的用例中,我需要模拟 GSuite 的电子邮件地址才能阅读和修改 Gmail 邮件。我通过域范围委派和 python 方法creds.with_subject(TARGET_EMAIL) 来做到这一点。是否有使用 google.auth 包及其 ADC 机制的等效方法?
      • 服务帐号密钥文件和 Cloud Run 上的 ADC 机制没有区别。您拥有为端点提供服务以获取凭据的元数据服务器,而不是文件。但是,如果您使用您的用户凭证在本地进行测试,您可能会遇到一些问题(您可以修复,但不是那么简单!)
      • 您帖子中的凭据对象似乎没有with_subject 属性,因此凭据不同(我收到属性错误)。然而,这个错误导致我发现了这个answer。它缺少身份验证范围,但在此之后,问题得到了解决。我将添加一个答案
      【解决方案3】:

      使用Secret Manager 可能会对您有所帮助,因为您可以管理您拥有的多个机密,而不是将它们存储为文件,就像您现在正在做的那样。我建议你看看这篇文章here,这样你就可以获得更多关于如何将它与 Cloud Run 一起使用的信息,从而改进你管理机密的方式。

      除此之外,正如在类似案例here 中所阐明的那样,您有两个选择:使用随附的默认服务帐户或部署另一个具有Service Admin 角色的服务帐户。这样,您就不需要使用变量指定键 - 正如 Google 开发人员在此特定 answer 中所阐明的那样。

      【讨论】:

      • 如果我理解正确,这个流程意味着我需要授予服务帐户访问 Secret Manager API 的权限,然后,只需使用环境提供的默认凭据,我就可以访问我设置了,哪些可能是我需要的其他 API 或云服务的密钥?
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-03-16
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多