@roberthbailey @zmerlynn @erictune

Will #7101 do this for us automatically? @liggitt

I see that we already have:

$ kubectl get secrets
NAME                              TYPE      DATA
token-admin                       Opaque    1
token-kube-proxy                  Opaque    1
token-kubelet                     Opaque    1
token-system-controller-manager   Opaque    1
token-system-dns                  Opaque    1
token-system-logging              Opaque    1
token-system-monitoring           Opaque    1
token-system-scheduler            Opaque    1

For GCE/GKE we do (@erictune added them to cluster/gce/configure-vm.sh).

Note that these are all just bearer tokens and they don't contain the CA root cert which we need to distribute for #7964.

#7101 will get automatically get you bearer tokens for service accounts, but that's it. There was discussion about following that with adding a kubeconfig key to the secret which bundled the ca cert and the token together

Let's not use the admin account for pods. Secrets are for pods. So let's
not put the admin secrets in secret resources.
On May 8, 2015 12:56 PM, "Jordan Liggitt" notifications@github.com wrote:

#7101 #7101 will
get automatically get you bearer tokens for service accounts, but that's
it. There was discussion about following that with adding a kubeconfig key
to the secret which bundled the ca cert and the token together

—
Reply to this email directly or view it on GitHub
#7979 (comment)
.

@erictune : have I done the wrong thing in PR ##7988 ?

I created token-system-logging with the hope that it would be used for elasticsearch. So I am a little sad that #7988 used token-admin. 😿

Let me look into this and see if I can switch to token-system-logging

What's the status on this? It seems that tokens are a big issue for many people but I guess a lot of it has to do with doing upgrades. Do we think this issue is something we want to do? If not, let's close it out.

I can't help thinking that we will keep wanting to make system pods that want to make Kuebernetes API calls but perhaps we should wait until there is a clear demand for this scenario.

Doesn't service accounts handle this?

On Fri, Jun 5, 2015 at 12:42 AM, Satnam Singh notifications@github.com
wrote:

I can't help thinking that we will keep wanting to make system pods that
want to make Kuebernetes API calls but perhaps we should wait until there
is a clear demand for this scenario.

—
Reply to this email directly or view it on GitHub
#7979 (comment)
.

Doesn't service accounts handle this?

Yes. Room for improvement (including the CA or a kubeconfig with the token as well), but yes... that's how pods get API credentials.