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