我目前正在开发一个项目,该项目将自动设置一个新的Firebase / Gcloud项目。它在很大程度上依赖于具有用户凭据的Firebase CLI和gcloud SDK的几个强制步骤。
我现在正在尝试将该项目移至Cloud Run上的Docker容器。我已经能够使用他们的built-in token-based CI command用户凭据对Firebase CLI进行身份验证。
我想问问是否可以使用类似方法对gcloud SDK进行身份验证。
为什么服务帐户可能无法使用
我意识到,这样的“服务到服务”程序应该通过服务帐户进行身份验证。但是,就我而言,程序的流程如下:
我无法使用服务帐户对步骤2中的请求进行身份验证,因为该项目才刚刚创建,因此我还没有机会授予任何服务帐户编辑或下载密钥的权限,文件。这就是为什么我要使用代表用户凭据的令牌进行身份验证的原因。
默认情况下,Cloud Run环境实际上可以访问托管该容器的项目的服务帐户。由于此服务帐户无权编辑新创建的项目,因此使用它进行身份验证是没有意义的。
到目前为止的想法
gcloud auth login --no-launch-browser
-需要用户交互,并且提供的密钥在每个登录会话中似乎都是唯一的编辑: 我的意图是允许技术含量较低的大学通过单击按钮来创建具有大量预定义设置的新Firebase项目。这包括以下步骤:
创建的Google Cloud项目必须是我们Google Cloud组织的一部分。项目的所有者并不重要,因为我在创建后手动设置了IAM角色。
以上所有步骤都在我的本地系统上运行,当我使用想法4时,它们也在Cloud Run之外的通用Docker容器上运行。我正在处理的问题是验证对step #2和step #3的请求。由于这两个请求都与新创建的项目有关,因此Cloud Run的默认服务标识此时不具备验证这些请求所需的角色。这就是为什么我正在寻找一种方法来通过Firebase CLI在步骤#1中使用的相同用户凭据进行身份验证,因为这些凭据默认情况下将具有所有者特权。
答案 0 :(得分:1)
我不确定您想要实现什么。而且即使有可能被黑客入侵,您也不知道由于版本更新或API更改而一天会被破解。
此外,在VM上运行的应用程序中使用个人帐户也不是一个好主意。日志将以用户身份而不是应用程序身份(服务帐户)跟踪您。您的个人操作(在计算机上以及对云的访问)和应用程序的操作(代表您执行的操作)是什么?
如果您担心部署,可以看看terraform,甚至可以编写自己的部署脚本。
我不确定您是否遇到了所有的阻止程序和问题,请告诉我们更多信息,也许有不错的解决方法!