英文:
How to create new client certificates / tokens for programmatic access to the Kubernetes API hosted on GKE?
问题
我正在运行一个托管在GKE上的Kubernetes集群,并希望编写一个使用Go语言编写的应用程序,与Kubernetes API进行通信。据我了解,为了与apiserver进行身份验证,我可以提供客户端证书、令牌或HTTP基本身份验证。我已经找到了将这些内容注入到Golang客户端库中的正确位置。
不幸的是,我遇到的示例通常引用了存储在我的个人kubeconfig文件中的现有凭据。从安全的角度来看,这似乎是不可取的,并且让我相信我应该创建一个新的客户端证书/令牌/用户名密码对,以便支持轻松撤销/删除被入侵账户。然而,我在文档中找不到实际描述在GKE上运行时如何操作的地方。(有一个关于创建新证书的指南,解释了apiserver最终需要使用更新的参数重新启动,据我了解,这在GKE上无法完成。)
重用个人Kubernetes凭据在一个(或多个)应用程序中是否存在安全问题?如果存在问题,生成新凭据的正确方法是什么?
谢谢。
英文:
I am running a Kubernetes cluster hosted on GKE and would like to write an application (written in Go) that speaks to the Kubernetes API. My understanding is that I can either provide a client certificate, bearer token, or HTTP Basic Authentication in order to authenticate with the apiserver. I have already found the right spot to inject any of these into the Golang client library.
Unfortunately, the examples I ran across tend to reference to existing credentials stored in my personal kubeconfig file. This seems non-advisable from a security perspective and makes me believe that I should create a new client certificate / token / username-password pair in order to support easy revocation/removal of compromised accounts. However, I could not find a spot in the documentation actually describing how to go about this when running on managed Kubernetes in GKE. (There's this guide on creating new certificates explaining that the apiserver needs to get restarted with updated parameters eventually, something that to my understanding cannot be done in GKE.)
Are my security concerns for reusing my personal Kubernetes credentials in one (or potentially multiple) applications unjustified? If not, what's the right approach to generate a new set of credentials?
Thanks.
答案1
得分: 2
如果您的应用程序在集群内运行,您可以使用Kubernetes服务账户来进行API服务器的身份验证。
如果应用程序在集群外运行,情况就不那么简单了,我想您的担忧是合理的。目前,GKE不允许使用除了为您的个人kubeconfig文件生成的身份之外的其他自定义身份。
您可以获取一个服务账户的令牌(在Pod内部,从/var/run/secrets/kubernetes.io/serviceaccount/token
读取),然后使用该令牌进行身份验证。这是一种不太理想的解决方案,也不是一个很好的通用解决方案,但可能比使用您自己的个人凭据稍微好一些。
英文:
If your application is running inside the cluster, you can use Kubernetes Service Accounts to authenticate to the API server.
If this is outside of the cluster, things aren't as easy, and I suppose your concerns are justified. Right now, GKE does not allow additional custom identities beyond the one generated for your personal kubeconfig file.
Instead of using your credentials, you could grab a service account's token (inside a pod, read from /var/run/secrets/kubernetes.io/serviceaccount/token
), and use that instead. It's a gross hack, and not a great general solution, but it might be slightly preferable to using your own personal credentials.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论