No worries! Glad you got it working.
Could kubectl logging been more helpful to help you identifying this error
faster? Please put up a PR or issue if you think it could have.
On Wed, Feb 22, 2017, 3:30 PM Rudy Bonefas wrote:
> Ok, I figured out my problem. I'm an idiot.
>
> I had a working ve
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 shoul
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
cc'ing Eric Chiang who worked on the caching code.
On Mon, Feb 20, 2017 at 7:09 AM Rudy Bonefas 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
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 infor
