Ok, I figured out my problem. I'm an idiot. I had a working version using some test code. In addition to using OpenID from kubectl we are also using our own API proxy. Somehow when I moved my test code over to our staging API proxy I turned https off in the proxy. Apparently (and as it should do now that I think about it), kubectl will NOT send a token to a server that is not running SSL. This makes perfect sense to me NOW, since I wouldn't want a man in the middle attack to grab my token even if it expires within a 24 hour period.
Thanks for you help and in indulging my stupidity On Tuesday, February 21, 2017 at 7:54:12 PM UTC-5, Eric Chiang wrote: > > Rudy, > > The OpenID Connect client auth provider only caches in memory[0]. It > doesn't persist that information to disk. If you're not seeing the > request on subsequent invocations of kubectl then you're not > exercising the plugin. At least that's what the code would do if there > isn't a bug. > > Does your kubectl still send the bearer token despite not hitting the > well-known endpoint? > > Eric > > [0] > https://github.com/kubernetes/client-go/blob/v2.0.0/plugin/pkg/client/auth/oidc/oidc.go > > > On Tue, Feb 21, 2017 at 4:30 PM, Brandon Philips > <brandon...@coreos.com <javascript:>> wrote: > > cc'ing Eric Chiang who worked on the caching code. > > > > On Mon, Feb 20, 2017 at 7:09 AM Rudy Bonefas <rudy...@gmail.com > <javascript:>> wrote: > >> > >> We have decided to use OpenID Connect with Kubectl and I have been in > the > >> process if writing an OpenID Connect server using the nimbusds java > sdk. > >> When kubectl first connects to my server using the > >> /.well-known/openid-configuration endpoint, it obviously caches the > returned > >> configuration information somewhere because I see no subsequent calls > to the > >> same endpoint. For testing purposes I would like to clear this cache > but am > >> unable to figure out where Kubectl is saving this information. I've > tried > >> deleting the .kube/cache dir as well as the /tmp dir (I am running on > >> Centos7) but to no avail. Does anyone know how I can reset Kubectl to > >> start up with a fresh set of OpenID config settings? > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Kubernetes user discussion and Q&A" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to kubernetes-use...@googlegroups.com <javascript:>. > >> To post to this group, send email to kubernet...@googlegroups.com > <javascript:>. > >> Visit this group at https://groups.google.com/group/kubernetes-users. > >> For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
