cmd/kube-proxy/app/server.go does BindClientConfigFlags, but there is no flag to set the Token

Options:

1. change kube-proxy to do clientauth.LoadFromFile(filename) to load a kubernetes_auth file, like kubelet does. @jlowdermilk didn't you have some reason to not like continued use of kubernetes_auth files? Does that only apply to human/desktop clients, or also to in-pod clients?
2. add a flag --token= which BindClientConfigFlags will use. Don't like this one because it is putting secret on the command line where it may accidentally be pasted, or otherwise seen.
3. add a TokenFile option to client.Config which tells the Client to read just the token from a file. Make BindClientConfigFlags be able to set this with a --token-file argument. Problem here is need to define a new file format.
4. @deads2k should kube-proxy be using pkg/client/clientcmd and if so how?

The motivation for deprecating kubernetes_auth files is mainly that they complicate loading rules when used with kubeconfig files. Even if they didn't, I think there is value in having one consistent way of storing and loading auth config, and that way should probably be kubeconfig.

I would go with 4. It should be fairly easy to have the kubeproxy load the token from a kubeconfig file, and change the salt rule to manage a kubeconfig file instead of a kubernetes_auth file.

@jlowdermilk

Should I do

• { "config": { "users" : [ {...} ] } } or
• { "config": { "contexts" : [ {"user" : { ... } } ] } }

If the second one, what do I say for the cluster name? Not sure that is readily available in the place where I want to generate this file.

Can I do:

• "user" : {"authPath" : "/var/lib/kubelet/kubernetes_auth" }
• or do I need to do "user" : {"token" : "asdfk" }

You can load a kubeconfig directly from a single file using:

    loader := clientcmd.NewNonInteractiveDeferredLoadingClientConfig(&clientcmd.ClientConfigLoadingRules{ExplicitPath: kubeConfigFile}, &clientcmd.ConfigOverrides{})

@erictune, it's probably simplest to just load the auth bits from kubeconfig to start. We can consider loading endpoint data (i.e. "cluster") for the master later if it makes it cleaner.

You could specify an authPath, but that would counter the goal of using kubeconfig and not kubernetes_auth. I'd recommend a kubeconfig that looks like

apiVersion: v1
kind: Config
users:
- name: kubelet
  user:
    token: asdfk

Then in cmd/kube-proxy/app/server.go, you can load and access the token with

config := clientcmd.LoadFromFile("/path/to/kubeconfig")
token := config.AuthInfos["kubelet"].Token

@deads2k, is the loader actually necessary if you just want to load a single file without merge rules? I think the above should work fine, but pls correct if I'm wrong.

@jlowdermilk LoadFromFile does not resolve relative paths (if it did, you'd never be able to know what the file actually contains). If you have references to certs and keys, you might need to use clientcmd.ResolveLocalPaths.

@jlowdermilk
We aren't doing node upgrades yet, right? Because changing the auth file format and changing what format the kubelet and kube-proxy expect would require that the upgrade change them both at once.

@deads2k @jlowdermilk
Okay, so if I do:
config := clientcmd.LoadFromFile("/path/to/kubeconfig")
I get a "pkg/client/clientcmd/api".Config. How do I turn that into a "pkg/client".client?

Oh, I need to do:

loader := clientcmd.NewNonInteractiveDeferredLoadingClientConfig(&clientcmd.ClientConfigLoadingRules{ExplicitPath: kubeConfigFile}, &clientcmd.ConfigOverrides{})

and then do:
client := client.New(loader.ClientConfig())

Wow that is a lot of work to make a client!

The minimum file that is usable appears to be this:

apiVersion: v1
kind: Config
users:
- name: kubelet
  user:
    token: abc123
clusters:
- name: local
  cluster:
     server: https://kubernetes-master:6443
     insecure-skip-tls-verify: true
contexts:
- context:
    cluster: local
    user: kubelet
  name: onlycontext
current-context: onlycontext

A bit more verbose that I had hoped for.

Wow that is a lot of work to make a client!

If you have a config in memory, you can use clientcmd.NewDefaultClientConfig(), but that won't resolve paths relative to a file location. We just recently started tracking LocationOfOrigin for stanzas, so I think we have sufficient information to make a cleaner load method now. Just a thought, but I don't think I'll be able to get to that in the short term.

@erictune: @mbforbes is working on upgrade testing right now. That said, if we happen to break it ... I'm not sure anyone would run you through the ringer.

been working on this for last few days. just hitting one stumbling block after another with salt and startup scripts.

Fixed by #7303