【问题标题】:Can I authenticate gcloud cli using both service account and user credentials?我可以同时使用服务帐户和用户凭据对 gcloud cli 进行身份验证吗?
【发布时间】:2018-07-09 10:03:54
【问题描述】:

Google API 客户端通常会识别 GOOGLE_APPLICATION_CREDENTIALS 环境变量。如果找到,它应该指向一个 JSON 文件,其中包含服务帐户或用户的凭据。

可以从 GCP 网络控制台下载服务帐户凭据,如下所示:

{
  "type": "service_account",
  "project_id": "...",
  "private_key_id": "...",
  "private_key": "...",
  "client_email": "...",
  "client_id": "...",
  "auth_uri": "...",
  "token_uri": "...",
  "auth_provider_x509_cert_url": "...",
  "client_x509_cert_url": "..."
}

用户凭据通常在 ~/.config/gcloud/application_default_credentials.json 中可用,类似于:

{
  "client_id": "...",
  "client_secret": "...",
  "refresh_token": "...",
  "type": "authorized_user"
}

这是官方 google ruby​​gem detecting the type of credentials provided via the environment var 的示例。

我想使用两种类型的凭据对未配置的 gcloud 安装进行身份验证。在我们的例子中,我们碰巧将 GOOGLE_APPLICATION_CREDENTIALS 变量和路径传递到 docker 容器中,但我认为这对于在 docker 外部进行全新安装也是一个有效的问题。

如果凭证文件是服务帐户类型,我可以这样做:

gcloud auth activate-service-account --key-file=${GOOGLE_APPLICATION_CREDENTIALS}

但是我看不到任何方法来处理凭据属于真实用户的情况。

问题:

  1. 为什么官方 gcloud 工具不遵循其他 google API 客户端使用的约定并在可用时使用GOOGLE_APPLICATION_CREDENTIALS
  2. 是否有隐藏方法可以激活用户凭据案例?

【问题讨论】:

    标签: gcloud gcloud-cli


    【解决方案1】:

    正如您所指出的,gcloud 命令行工具 (CLI) 不使用应用程序默认凭据。它有单独的系统来管理自己的凭据。

    GOOGLE_APPLICATION_CREDENTIALS 专为客户端库而设计,以简化凭据中的布线,而 gcloud CLI 不是库。即使在客户端代码中,最佳实践也不是依赖此环境变量,而是显式提供凭据。

    要回答您的第二个问题,可以通过以下方式获取用户凭据

    gcloud auth login
    

    命令。 (注意这与gcloud auth application-default login 不同)除了保存实际凭据之外,还会在当前配置中设置account 属性:

     gcloud config list
    

    gcloud 可以有许多配置,每个配置都有不同的凭据。见

    gcloud config configurations list
    

    您可以创建多个配置,一个使用用户帐户,另一个使用服务帐户,并通过提供--configuration参数同时使用,例如

    gcloud compute instances list --configuration MY_USER_ACCOUNT_CONFIG
    

    同样,您也可以使用--account 标志切换使用哪些凭据,在这种情况下,它将使用相同的配置并且只会换出帐户。

    【讨论】:

    • 感谢您提供详细信息。我的挑战是我已经有一个配置 gcloud 的环境(在我的笔记本电脑上)(同时使用 gcloud auth 登录和 gcloud auth 应用程序默认登录),我想与全新的 glcoud 安装共享该配置,而无需重新进行身份验证.
    • gcloud info --format="value(config.paths.global_config_dir)" 会告诉您 gcloud 配置的位置。在类 Unix 系统上,它是 ~/.config/gcloud。简单地将这个配置目录复制到新机器应该允许新安装来选择它。您还可以将 CLOUDSDK_CONFIG 环境变量设置为新位置以供 gcloud 使用。 (在这种情况下,您可能还需要设置 GOOGLE_APPLICATION_CREDENTIALS。)
    • 谢谢。所以没有办法安装新的 gcloud 来加载有效的 GOOGLE_APPLICATION_CREDENTIALS 凭据(即auth activate-service-account --key-file=${GOOGLE_APPLICATION_CREDENTIALS} 的用户版本)?
    • 没错。它们是通过两种不同的方法获得的。一个通过gcloud auth login 和另一个gcloud auth application-default login,在后台是不同的凭据。即使您在 gcloud 中成功“激活”了应用程序默认凭据,您也会发现许多 gcloud cli 命令将停止工作,或者某些 API 调用的配额会被限制在低得多的配额。用户应用程序默认凭据仅用于测试/调试/演示目的,不会在任何严重的生产环境中使用它们。请改用服务帐号。
    • @cherba - 你有没有参考你评论“停止工作......”。我一直在深入研究 Google Cloud 凭据,但我认为您的评论不正确。我一直在为我的个人博客写文章,其中包含很多细节。你们的 cmets 可能会改变我的文章。 www.jhanley.com
    【解决方案2】:

    GOOGLE_APPLICATION_CREDENTIALS 指向具有用户凭据而不是服务帐户凭据的文件时,我找到了一种验证新 gcloud 的方法。

    cat ${GOOGLE_APPLICATION_CREDENTIALS}
    {
     "client_id": "aaa",
     "client_secret": "bbb",
     "refresh_token": "ccc",
     "type": "authorized_user"
    }
    
    gcloud config set auth/client_id aaa                                                                                             
    gcloud config set auth/client_secret bbb                                                                                     
    gcloud auth activate-refresh-token user ccc
    

    这使用了未记录的 auth activate-refresh-token 子命令 - 这并不理想 - 但它确实有效。

    gcloud auth activate-service-account --key-file=credentials.json 配合使用,无论$GOOGLE_APPLICATION_CREDENTIALS 提供的凭据类型如何,都可以初始化gcloud

    【讨论】:

    • 这不是个好主意。一个未记录的命令可能会消失,两个你会开始遇到奇怪的 API 错误。
    • 感谢您的提醒。到目前为止,它对我们来说运行良好,但我会留意可能相关的无法解释的问题。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-07-13
    • 2022-08-04
    • 2020-06-24
    • 1970-01-01
    • 2020-07-23
    • 1970-01-01
    • 2017-03-20
    相关资源
    最近更新 更多