<p>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 <a href="https://github.com/kubernetes/kubernetes/tree/release-1.1/pkg/client/" rel="nofollow">Golang client library</a>.</p>

<p>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 <a href="http://kubernetes.io/docs/admin/authentication/" rel="nofollow">this guide on creating new certificates</a> explaining that the apiserver needs to get restarted with updated parameters eventually, something that to my understanding cannot be done in GKE.)</p>

<p>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?</p>

<p>Thanks.</p>

<p>If your application is running inside the cluster, you can use <a href="http://kubernetes.io/docs/user-guide/service-accounts/" rel="nofollow">Kubernetes Service Accounts</a> to authenticate to the API server.</p>

<p>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.</p>

<p>Instead of using your credentials, you could grab a service account's token (inside a pod, read from <code>/var/run/secrets/kubernetes.io/serviceaccount/token</code>), 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.</p>
