使用用户凭据在Cloud Run中验证gcloud SDK

时间:2020-04-01 09:52:07

标签: docker google-cloud-platform gcloud google-cloud-run

我目前正在开发一个项目,该项目将自动设置一个新的Firebase / Gcloud项目。它在很大程度上依赖于具有用户凭据的Firebase CLIgcloud SDK的几个强制步骤。

我现在正在尝试将该项目移至Cloud Run上的Docker容器。我已经能够使用他们的built-in token-based CI command用户凭据对Firebase CLI进行身份验证。

我想问问是否可以使用类似方法对gcloud SDK进行身份验证。

为什么服务帐户可能无法使用

我意识到,这样的“服务到服务”程序应该通过服务帐户进行身份验证。但是,就我而言,程序的流程如下:

  1. 使用Firebase CLI创建新的gcloud / firebase项目
  2. 使用gcloud SDK为新项目添加IAM绑定,启用API,计费等

我无法使用服务帐户对步骤2中的请求进行身份验证,因为该项目才刚刚创建,因此我还没有机会授予任何服务帐户编辑或下载密钥的权限,文件。这就是为什么我要使用代表用户凭据的令牌进行身份验证的原因。

默认情况下,Cloud Run环境实际上可以访问托管该容器的项目的服务帐户。由于此服务帐户无权编辑新创建的项目,因此使用它进行身份验证是没有意义的。

到目前为止的想法

  1. gcloud auth login --no-launch-browser-需要用户交互,并且提供的密钥在每个登录会话中似乎都是唯一的
  2. 由于已使用用户凭据对Firebase CLI进行了身份验证,也许有一种方法可以用来对gcloud SDK进行身份验证?
  3. 是否可以让服务帐户继承用户的所有权限?我已经看到了几个示例,但是它们仅适用于每个项目级别。我意识到这种解决方案看起来多么糟糕。
  4. gcloud SDK似乎将用户凭据保存在/root/.config/gcloud文件夹中。在设置我的Docker容器时,我违反了所有明智的逻辑,并复制了该文件夹。当我在本地Docker容器上运行它时,这确实有效,但是当我在Cloud Run上运行它时,默认服务帐户似乎会覆盖所有其他凭据。本地Docker容器可以访问复制的配置,但是即使文件复制成功,gcloud SDK似乎也无法识别它们。

编辑: 我的意图是允许技术含量较低的大学通过单击按钮来创建具有大量预定义设置的新Firebase项目。这包括以下步骤:

  1. 设置一个新的Firebase项目(它会自动设置一个新的Google Cloud项目)
  2. 启用结算
  3. 设置用户IAM角色并升级/下载服务帐户
  4. 添加Google Analytics(分析)
  5. 添加云存储
  6. 创建新的云存储桶
  7. 添加Firestore纯模式
  8. 复制预定义的云功能和安全角色并将其部署到云中

创建的Google Cloud项目必须是我们Google Cloud组织的一部分。项目的所有者并不重要,因为我在创建后手动设置了IAM角色。

以上所有步骤都在我的本地系统上运行,当我使用想法4时,它们也在Cloud Run之外的通用Docker容器上运行。我正在处理的问题是验证对step #2step #3的请求。由于这两个请求都与新创建的项目有关,因此Cloud Run的默认服务标识此时不具备验证这些请求所需的角色。这就是为什么我正在寻找一种方法来通过Firebase CLI在步骤#1中使用的相同用户凭据进行身份验证,因为这些凭据默认情况下将具有所有者特权。

1 个答案:

答案 0 :(得分:1)

我不确定您想要实现什么。而且即使有可能被黑客入侵,您也不知道由于版本更新或API更改而一天会被破解。

此外,在VM上运行的应用程序中使用个人帐户也不是一个好主意。日志将以用户身份而不是应用程序身份(服务帐户)跟踪您。您的个人操作(在计算机上以及对云的访问)和应用程序的操作(代表您执行的操作)是什么?

如果您担心部署,可以看看terraform,甚至可以编写自己的部署脚本。

我不确定您是否遇到了所有的阻止程序和问题,请告诉我们更多信息,也许有不错的解决方法!