[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Multi Clusters : Token management

Thanks guys for having some discussion on this topic. Pl confirm whether my understanding is correct or not pertaining to multi cluster authentication and token management. 

1. OSE3 authentication sub system can use external oAuth based solution ( corporate solution). This SSO only works for browser based clients ( console etc) but not CLI clients like OC etc

2. Client cert bases solution might help both browser and CLI but it is difficult to operate and manage unless decent PKI infrastructure available for cert issuing and revocation

3. It’s not best practice to have same token being used across multiple clusters and no efforts currently going to integrate. It is assumed that each cluster has its own token key and lifetime. 

4. If client dealign with multiple clusters and his applications spread across all these clusters, they have to authenticate on each cluster to manage. His .kube/config file might have details all these clusters and login separately. Administrators can increase the token validity to reduce number of login attempts but that is still pain from experience perceptive.

Please add any helpful ideas to provide simple authentication layer in a multi cluster environment

Srinivas Kotaru

On 2/22/16, 12:03 AM, "Aleksandar Kostadinov" <akostadi redhat com> wrote:

>Jordan Liggitt wrote on 02/22/2016 09:43 AM:
>>         Correct, that method relies on the API server directly
>>         identifying the
>>         user from the certificate. That works for the few built in bootstrap
>>         users, and can work for end users if that particular certificate
>>         format is acceptable, but it lacks the administration tools and
>>         flexibility an actual PKI + auth proxy layer would give you.
>>     Excuse me for the ignorance, but how about PKI *without* a proxy
>>     layer? Wouldn't that allow flexibility with lower complexity?
>> How the subject of a client certificate maps to a user varies. The API
>> x509 auth expects a particular mapping (CN maps to username, OUs map to
>> groups) which works for the bootstrap cert users, but might not match
>> the subjects created by other PKIs.
>Thank you, very useful, then that means if the PKI is solely used for 
>OpenShift certificates generation it can be made working without a 
>proxy. Also if existing system happens to set CN and OU to strings that 
>are acceptable as user/group names in OpenShift it can also work.
>>     Certificate revocations can be handled by OCSP?
>> I haven't worked with OCSP for client certs... is stapling supported?
>IIRC I've tried client cert OCSP validation in the past. No idea about 
>stapling. I'd assume it would depend on the client as onus is on the 
>cert owner to send a signature. I'd be surprised if stapling worked. The 
>server most probably needs to do the OCSP validation.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]