github验证账户_使用服务帐户进行简单的gcp身份验证

github验证账户

A practical guide for using GCP Service Accounts to authenticate and use Google Cloud APIs easily and securely.

有关使用GCP服务帐户轻松安全地进行身份验证和使用Google Cloud API的实用指南。

In order to use Google Cloud Products, applications must first authenticate to Google and check IAM permissions. While Google’s IAM documentation page goes into meticulous detail about security best practices, as a non-security engineer, it’s hard to parse through all the text and apply Google’s recommendations for each use case. I know that I’m supposed to enforce least privilege for my service accounts, but what’s the best way to authenticate with Google SDKs while developing locally vs. giving access on GKE? In this post, I’ll summarize the recommendations for common use cases when interacting with Google Cloud.

为了使用Google Cloud产品，应用程序必须首先向Google进行身份验证并检查IAM权限。 虽然Google的IAM文档页面详细介绍了有关安全最佳实践的细节，但作为一名非安全工程师，很难分析所有文本并针对每个用例应用Google的建议。 我知道我应该为我的服务帐户强制执行最低特权，但是在本地开发与授予GKE访问权限时，通过Google SDK进行身份验证的最佳方法是什么？ 在本文中，我将总结与Google Cloud交互时常见用例的建议。

使用CLI(gcloud，terraform) (Using the CLI (gcloud, terraform))

If you are mostly interacting with GCP via CLI (either invoking gsutil , gcloud, or creating GCP components via terraform ), create a service account with respective roles, and use the service account impersonation feature. Until recently, the GCP console provided users with the option to create and download keys when creating a service account. Now that option is hidden in the default creation workflow, and users must click on the service account options to manually create keys.

如果您主要是通过CLI与GCP交互(调用gsutil ， gcloud或通过terraform创建GCP组件)，请创建具有相应角色的服务帐户 ，并使用服务帐户模拟功能 。 直到最近，GCP控制台还为用户提供了创建服务帐户时创建和下载密钥的选项。 现在，该选项已隐藏在默认的创建工作流程中，用户必须单击服务帐户选项才能手动创建密钥。

All Google Cloud APIs authenticate using OAuth2. When you generate a service account key, it creates a public/private key pair that is used to sign a JWT token to authentical GCP credentials. While this is convenient, downloading keys are considering dangerous as it could be accidentally checked into version control and does not expire (default expiration date is Dec 31, 9999). GCP supports key rotation, but centrally enforcing that is really difficult unless you have tools like Vault set up to automate that process.

所有Google Cloud API均使用OAuth2进行身份验证。 当您生成服务帐户密钥时，它会创建一个公用/专用密钥对，该对密钥用于将JWT令牌签名为真实的GCP凭据。 虽然这很方便，但是下载密钥被认为是危险的，因为它可能会被意外检查到版本控制中并且不会过期(默认有效期为9999年12月31日)。 GCP支持密钥轮换，但是集中执行实际上非常困难，除非您已设置诸如Vault之类的工具来自动执行该过程 。

The good news is that you can impersonate a service account to authenticate without needing to download keys. First, you need the serviceAccountTokenCreator role and run --impersonate-service-accouunt=<sa-name>@project.iam.gservicaccount.com with regular gcloud commands. You can also set your config to avoid passing in the command every time:

好消息是您可以模拟服务帐户进行身份验证，而无需下载密钥。 首先，您需要serviceAccountTokenCreator角色，并使用常规gcloud命令运行--impersonate-service-accouunt=<sa-name>@project.iam.gservicaccount.com 。 您还可以设置配置以避免每次都传入命令：

gcloud config set auth/impersonate_service_account \
  <sa-name>@project.iam.gserviceaccount.com

As for Terraform, set the GOOGLE_OAUTH_ACCESS_TOKEN variable to pass an OAuth2 token:

至于Terraform，请将GOOGLE_OAUTH_ACCESS_TOKEN变量设置为传递OAuth2令牌：

export GOOGLE_OAUTH_ACCESS_TOKEN=$(gcloud auth print-access-token)

Now you can run terraform commands with a short-lived token instead of downloading keys that you have to securely manage. Ryan Canty from Google wrote up a good article about this topic with example bash scripts to switch between multiple service accounts:

现在，您可以使用短暂的令牌运行terraform命令，而不必下载必须安全管理的密钥。 Google的Ryan Canty用示例bash脚本撰写了一篇有关此主题的好文章，以在多个服务帐户之间进行切换：

本地/非GCP开发 (Local/Non-GCP Development)

All Google Cloud Client libraries use an underlying auth library called Application Default Credentials (ADC) to automatically find and set service account credentials. It looks for credentials in the following order:

所有Google Cloud Client库都使用称为应用程序默认凭据(ADC)的基础身份验证库来自动查找和设置服务帐户凭据。 它按以下顺序查找凭据：

1. It checks if env variable GOOGLE_APPLICATION_CREDENTIALS is set. If it is, it uses the service account file that the env points to.

   它检查是否设置了环境变量GOOGLE_APPLICATION_CREDENTIALS 。 如果是，它将使用env指向的服务帐户文件。

2. If the variable is not set, then it uses the default service account.
   如果未设置该变量，则它将使用默认服务帐户。
3. If ADC can’t use any of the above, it errors out.
   如果ADC无法使用以上任何一种，则会出错。

This gives developers two choices to authenticate:

这为开发人员提供了两种选择进行身份验证：

1. Create a service account, download the keys to a secure location, and set GOOGLE_APPLICATION_CREDENTIALS

   创建服务帐户，将密钥下载到安全位置，然后设置GOOGLE_APPLICATION_CREDENTIALS

2. Use the gcloud auth application-default login to set your user credentials to ~/.config/gcloud/application_default_credentials.json

   使用gcloud auth application-default login您的用户凭据设置为~/.config/gcloud/application_default_credentials.json

While the second approach is more convenient for initial testing, it is not the recommended approach since it is using your user’s credentials as opposed to the service account’s permission scope, which most likely will be more restricted. Also, some SDK features such as Firebase Custom Tokens and GCS Signed URLs require the client_email field, which is not part of the application-default login credentials.

尽管第二种方法对于初始测试更为方便，但不建议使用这种方法，因为它使用的是用户凭据，而不是服务帐户的权限范围，后者很可能会受到更多限制。 另外，某些SDK功能(例如Firebase自定义令牌和GCS签名URL)需要client_email字段，该字段不是应用程序默认登录凭据的一部分。

The general recommendation from the Google team is to create and download the JSON credential file and set the path to GOOGLE_APPLICATION_CREDENTIALS. Given the security concerns listed above with these long-lasting keys, make sure to store it in a safe place and test on development GCP projects. For more information, check out Theodore Siu’s article on local development with GCP:

Google小组的一般建议是创建并下载JSON凭证文件，并将路径设置为 GOOGLE_APPLICATION_CREDENTIALS 。 鉴于上面列出的带有这些持久密钥的安全问题，请确保将其存储在安全的地方并在开发GCP项目上进行测试。 有关更多信息，请查看Theodore Siu的有关GCP本地开发的文章：

Note: This section also applies when calling GCP APIs on hybrid cloud architectures. For example, you may be using Google’s ML APIs from AWS or using Firebase for mobile development while keeping other compute workloads on different clouds.

注意：在混合云架构上调用GCP API时，本节也适用。 例如，您可能使用AWS的Google ML API或Firebase进行移动开发，同时将其他计算工作负载保留在不同的云上。

Google Cloud上的应用 (Applications on Google Cloud)

On Google Cloud, ADC automatically searches for default service account when running on Compute Engine, App Engine, Kubernetes Engine, Cloud Run, and Cloud Functions. The default service account has the Editor role and sets default auth scopes for various GCP products. For example, a GKE cluster created with the default service account gives read-only access to Storage and write access to Stackdriver Logging and Monitoring. If you need more granular access, you can create a new service account and attach it to use its IAM roles instead of the default service accounts.

在Google Cloud上，当在Compute Engine，App Engine，Kubernetes Engine，Cloud Run和Cloud Functions上运行时，ADC会自动搜索默认服务帐户。 默认服务帐户具有“编辑者”角色，并为各种GCP产品设置默认身份验证范围。 例如，使用默认服务帐户创建的GKE群集授予对存储的只读访问权限以及对Stackdriver Logging and Monitoring的写访问权限。 如果需要更细粒度的访问，则可以创建一个新的服务帐户，并将其附加为使用其IAM角色，而不是默认服务帐户。

As for giving containers access to Google Cloud resources, the recommended approach is to use Workload Identity. Workload Identity is similar to Amazon EKS IAM Roles for Service Accounts (IRSA) in that it gives Kubernetes service accounts (KSA) the ability to act as Google service accounts (GSA) when accessing Google Cloud APIs. Once Workload Identity is enabled on GKE, an identity pool called <project-id>.svc.id.goog is created.

至于让容器访问Google Cloud资源，建议的方法是使用 Workload Identity 。 Workload Identity与服务帐户的Amazon EKS IAM角色(IRSA)相似，因为它使Kubernetes服务帐户(KSA)能够在访问Google Cloud API时充当Google服务帐户(GSA)。 在GKE上启用工作负载标识后，将创建一个名为<project-id>.svc.id.goog的标识池。

To make a connection between KSA and GSA, first create both service accounts:

要在KSA和GSA之间建立连接，请先创建两个服务帐户：

$ kubectl create sa <ksa_name> -n 
$ gcloud iam service-accounts create <gsa-name>

Bind the IAM policy with the roles/iam.workloadIdentityUser role:

将IAM策略与roles/iam.workloadIdentityUser角色绑定：

$ 
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:<project_id>.svc.id.goog[k8s_namespace/ksa_name]" \
  <gsa_name>@<project_id>.iam.gserviceaccount.com

Finally, add an annotation to KSA:

最后，向KSA添加注释：

$ 
  --namespace <k8s_namespace> \
   <ksa_name> \
   iam.gke.io/gcp-service-account=<gsa_name>@<project_id>.iam.gserviceaccount.com

Workload Identity does have some limitations such as no support for GKE on-prem and Windows nodes. In that case, you can mount service account keys from secret and set GOOGLE_APPLICATION_CREDENTIALS , or use a tool like Vault secret injector.

Workload Identity确实有一些限制，例如不支持GKE本地和Windows节点。 在这种情况下，您可以通过秘密挂载服务帐户密钥并设置GOOGLE_APPLICATION_CREDENTIALS ，或使用Vault秘密注入器之类的工具。

最后的话 (Final Words)

I’m by no means a security expert, but you can follow these simple service account recommendations to securely access Google Cloud APIs even without a sophisticated secrets management setup. For the next steps, you can also check out the GCP CIS Benchmark Inspec Profile tool to make sure the appropriate IAM sections are covered in your project.

我绝不是安全专家，但是即使没有复杂的机密管理设置，您也可以按照这些简单的服务帐户建议来安全访问Google Cloud API。 对于后续步骤，您还可以检出GCP CIS基准Inspec配置文件工具 ，以确保项目中涵盖了适当的IAM部分。

翻译自: https://medium.com/dev-genius/simple-gcp-authentication-with-service-accounts-6b877c2e2649

github验证账户