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.
根据文档也此非常全面文章中，有两个用于auth的选项:
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:
UserWarning:您的应用程序已使用最终用户进行身份验证 来自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:
为什么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前端对话的用户凭据.您的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.
[END UPDATE]
[END UPDATE]
我将尝试提供有关您的问题的详细信息和建议.在确定最适合您的策略时，请考虑我以前的评论.
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.
那更新过程如何?
And what about the update process?
服务帐户凭据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屋！
