我们有一个系统，旨在同时管理位于外部客户帐户中的大量 Kubernetes 集群。该系统目前的工作方式是将kubeconfig数据存储在运行时查询的数据库中，然后像这样传递给 golang kube-client 构造函数：
clientcmd.NewClientConfigFromBytes([]byte(kubeConfigFromDB))
对于使用基本身份验证的集群，这“有效”。
对于 EKS 集群，只要aws-iam-authenticator在运行 golang 代码的机器上安装了 kube-client 以便 kube-client 可以调用它进行身份验证，并且更正API_AWS_ACCESS_KEY_ID并API_AWS_SECRET_ACCESS_KEY在kubeconfig's user.exec.envkey中设置，这就会起作用。
对于 GKE 集群，目前尚不清楚实现这一点的最佳实践方法是什么，尽管尝试了下面详述的一些不同操作，但我仍然无法使其工作。kubeconfig为 GKE 集群生成 a 的标准做法与 EKS 非常相似（详见https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl?authuser=1# generate_kubeconfig_entry )gcloud config config-helper用于生成身份验证凭据。
一个想法是使用GOOGLE_APPLICATION_CREDENTIALS环境变量，但问题在于它是全局的，因此我们不能让我们的系统同时与许多远程 GKE 集群通信，因为每个集群都需要一组唯一的 google 凭据来进行身份验证。
我的第二个想法是使用--impersonate-service-account提供给的标志gcloud config config-helper，但是当我运行它时它崩溃并出现以下错误：
$ gcloud config config-helper --format=json --impersonate-service-account=acct-with-gke-access@myorg.iam.gserviceaccount.com --project myproject
WARNING: This command is using service account impersonation. All …