On 19 September 2016 at 15:02, Marc Boorshtein <
marc.boorshtein(a)tremolosecurity.com> wrote:
On Mon, Sep 19, 2016 at 2:50 AM, Stian Thorgersen
<sthorger(a)redhat.com>
wrote:
> As kubectl is a CLI installed on end-user machines it's a public client.
For
> a CLI I'd use a system browser and make the CLI start a temporary web
server
> on localhost:XXXX, or I'd fallback to using resource owner password cred.
>
Thanks Stian, to be clear you're saying that you would NOT recommend
distributing the client secret to end users?
WIth Keycloak I'd go with a public client if you want the CLI to handle
retrieving tokens.
> ID token is an authentication token. So if you use that you should use
it to
> authenticate with the service kubectl invokes and set up a session
cookie to
> preserve the security context. Would make more sense to me to use the
access
> token though, and have kubectl responsible to refresh it.
I think what you are describing is similar to how OpenStack works
where you get a Keystone token after authenticating?
Not sure, I don't know the details of OpenStack or Keystone