GCP 客户端工具的最佳身份验证策略 [英] Best auth strategy for GCP client tool

问题描述

我想用python构建一个客户端gcp工具.

I want to build a client gcp tool in python.

我想避免通过 subprocess 调用 glcoud 工具，所以我选择了 sdk 客户端库 调用.

I want to avoid invocations of the glcoud tool via subprocess so I opt for sdk client library invocations.

根据文档以及 this 非常全面文章中，身份验证有两种选择:

According to the docs as also this very and comprehensive article, there are two options for auth:

a) 使用应用程序默认凭据(即 gcloud 在幕后使用的凭据)

a) using the application default credentials (i.e. the ones used by gcloud under the hood)

b) 使用服务帐户并将应用指向相应的 .json 文件.

b) using a service account and pointing the app to the corresponding .json file.

我已经尝试过 (a) 并收到以下警告:

I have already tried the (a) and got the following warning:

用户警告:您的应用程序已使用最终用户进行身份验证来自 Google Cloud SDK 的凭据.我们建议大多数服务器应用程序改为使用服务帐户.如果您的申请继续使用来自 Cloud SDK 的最终用户凭据，您可能会收到超出配额"或API 未启用"错误.更多有关服务帐户的信息，请参阅https://cloud.google.com/docs/authentication/
warnings.warn(_CLOUD_SDK_CREDENTIALS_WARNING)

UserWarning: Your application has authenticated using end user credentials from Google Cloud SDK. We recommend that most server applications use service accounts instead. If your application continues to use end user credentials from Cloud SDK, you might receive a "quota exceeded" or "API not enabled" error. For more information about service accounts, see https://cloud.google.com/docs/authentication/
warnings.warn(_CLOUD_SDK_CREDENTIALS_WARNING)

如果我使用应用默认凭据，这会很容易，因为应用将分发给每个最终用户，都会让这个 .json 文件成为他/她的身份验证过程的真实来源.但是，该应用可能会遇到上述quota exceeded 错误.

If I use app default creds, this makes it easy since each end user the app will be distributed to, will have this .json file a source of truth for his/her auth process. However, the app may encounter the above quota exceeded error.

在另一种情况下，(特定于服务帐户的凭据)我假设我必须向每个开发人员提供说明，以发布对应于与他/她具有完全相同权限的服务帐户的 json 文件.更新过程呢?每次用户被分配/撤销某些权限时会发生什么?这个 json 如何保持同步?

In the other case, (service account specific credentials) I assume I will have to provide instructions to each developer to issue a json file that corresponds to a service account with the exact same permission as his/hers. And what about the update process? What happens each time a user gets assigned / revoked some permissions? How this json stays in sync?

对此的任何建议将不胜感激.

Any advice about this would be highly appreciated.

推荐答案

应用程序默认凭据 (ADC) 有多种类型:用户帐户和服务帐户以及它们的变体.您问题中的警告消息意味着您使用用户帐户凭据(gcloud auth login)设置了 SDK CLI.我建议改用服务帐号凭据.

There are several types of application default credentials (ADC): User Account and Service Account and variations of those. The warning message in your question means that you set up the SDK CLI with user account credentials (gcloud auth login). I recommend switching to service account credentials.

此命令将使用服务帐户设置 CLI.您将需要项目 ID 和服务帐号 JSON 文件.

This command will setup the CLI with a service account. You will need your Project ID and service account JSON file.

gcloud auth activate-service-account test@PROJECT_ID.iam.gserviceaccount.com --key-file=service_account.json

我写了一篇文章，详细介绍了如何设置 CLI:

I wrote an article that goes into detail on how to set up the CLI:

使用服务帐户设置 Gcloud凭据

为什么 Google 会向您发出警告:

Why is Google giving you a warning:

• 授权用户凭据需要在 Google 的后端服务上付出更多努力.
• 用户帐户凭据需要人工交互才能创建.
• 刷新令牌通常由客户端或后端的软件存储.这会造成安全漏洞.
• 软件应使用具有有限权限(范围)的机器对机器身份验证.对于所进行的 API 调用，用户凭证通常被授予过多的权限.这又是一个安全问题.
• Google 已决定不允许用户凭据具有访问许多 Google Cloud Platform 服务所需的范围.这在创建 OAuth 客户端时非常明显，您会收到有关验证的重大警告.Google 将停止允许用户使用云服务凭据存在强烈风险.最好使用服务帐户支持的官方方法，以后不要遇到此问题.

• Authorizing User Credentials requires more effort on Google's backend services.
• User Account credentials require human interaction to create.
• The Refresh Token is often stored by software on the client or backends. This creates a security hole.
• Software should use machine-to-machine authentication with limited permissions (scopes). User credentials typically are issued with too many permissions for the API calls being made. This again is a security issue.
• Google has decided that User Credentials will not be allowed to have the scopes required to access many Google Cloud Platform services. This is very apparent when creating OAuth Clients and you receive a big warning about verification. There is a strong risk that Google will stop allowing user credentials for cloud services. It is better to use the supported and official method of a service account and not face this issue in the future.

但是，鉴于上述详细信息，您的用例正在为您的用户提供凭据.这不是一个好主意.我将继续使用用户凭据与您的 Web 前端交谈.您的网络前端使用用户永远不会看到的服务帐户并提供最终服务 (API) 访问权限.

However, given the above details, your use case is providing your users with credentials. This is not a good idea. I would continue to use User Credentials talking to your web frontend. Your web frontend uses a service account that the user never sees and provides the final service (API) access.

[更新]

我刚刚注意到您说您正在开发自己的 CLI.如果没有关于此 CLI 将访问哪些项目/服务的更多详细信息，您可能会考虑使用与您的服务对话的用户凭据，该服务会向用户发出访问令牌.此令牌仅在一小时内有效.您可以支持在代码中刷新此令牌.这使您能够使用用户身份验证、控制服务帐户的使用并仍然保持良好的安全性.请注意，我试图引导您不要将服务帐户文件直接分发给用户.如果这些用户是您自己的员工，则问题不大.对于不受您控制的人，请仔细考虑.

I just noticed your comment that you are developing your own CLI. Without more details on what projects/services this CLI will be accessing you might consider using user credentials that talk to your service which issues an Access Token to the user. This token is only valid for one hour. You can support refreshing this token in your code. This gives you the ability to use user authentication, control service account usage and still maintain good security. Notice that I am trying to steer you away from distributing service account files directly to users. If these users are your own employees, this is less of a problem. For people not under your control think carefully.

[结束更新]

我会尽力就您的问题提供详细信息和建议.在决定最适合您的策略时，请务必考虑我之前的评论.

I will try to provide details and advice on your questions. Do consider my previous comments while deciding the best strategy for you.

在另一种情况下，(服务帐户特定凭据)我假设我必须向每个开发人员提供说明以发出 json对应于具有完全相同的服务帐户的文件作为他/她的许可.

In the other case, (service account specific credentials) I assume I will have to provide instructions to each developer to issue a json file that corresponds to a service account with the exact same permission as his/hers.

如果我要编写一个使用服务帐户凭据的应用程序，我会创建一个方法来加载/安装凭据.只需提供一个文件并告诉他们在程序中执行此步骤即可.但是，您有一个问题.将相同的服务帐户分发给所有用户并不是一个好主意.你如何处理撤销等?Google Cloud Platform 服务帐号并非旨在为每个项目的数十或数百个用户单独分发.

If I were to write an application that used service account credentials, I would create a method to load/install the credentials. Just provide a file and tell them to do this step in the program. However, you have an issue. It is not a good idea to distribute the same service account to all users. How do you handle revoking, etc? Google Cloud Platform service accounts are not designed to be distributed uniquely to more than a few dozen or hundreds users per project.

更新过程呢?

服务帐户凭据 JSON 密钥文件不会过期.从服务帐户创建的令牌确实会过期，但这由 Google 客户端库管理或在您自己的代码中管理以自动刷新它们.

Service account credential JSON key files do not expire. The tokens created from the service account do expire but this is managed by Google client libraries or in your own code to automatically refresh them.

每次用户被分配/撤销某些权限时会发生什么?这个 JSON 如何保持同步?

What happens each time a user gets assigned/revoked some permissions? How this JSON stay in sync?

服务帐户文件不包含权限.这些存储在 Google Cloud IAM 中.修改分配给服务帐号的角色后，它们会在几分钟内透明地应用于全局.

The service account file does not contain permissions. These are stored in Google Cloud IAM. Once you modify the roles assigned to a service account, they are transparently applied globally within a few minutes.

这篇关于GCP 客户端工具的最佳身份验证策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！