The configurations listed at https://docs.openshift.com/enterprise/3.0/admin_guide/configuring_authentication.html integrate at the point of login, and result in an API token specific to that cluster. If logins go through a proxy that manages auth sessions and does not re-prompt users for credentials for the duration of that session, they might not care that they have different API tokens per server.
x509 client certificate auth directly against the API (as referenced in https://docs.openshift.org/latest/architecture/additional_concepts/authentication.html) is intended for a small set of "bootstrap" users (like the cluster administrator, and for various system components to talk to the API). As you mentioned, using this with lots of end users without an actual PKI to manage certificate generation/revocation/user mapping would likely be difficult to administer. The ideal scenario for end-user client cert auth would be a PKI to manage the certificates, and to log in through an auth proxy that would translate client certificates into usernames for OpenShift. I think that could be done for browser clients with the RequestHeader integration mentioned earlier, but the cli tools don't yet support obtaining an API token using a client certificate. On Fri, Feb 19, 2016 at 4:04 PM, Aleksandar Kostadinov <[email protected]> wrote: > Srinivas Naga Kotaru (skotaru) wrote on 02/19/2016 09:48 PM: > >> I don’t see any client cert based authentication but have seen “Request >> Header” based auth.It seems essentially sending to remote proxy server >> which does the authentication and authorization. Let me explore on this. >> > > ops, sorry, wrong link. Here's where x.509 auth is mentioned: > > > https://docs.openshift.org/latest/architecture/additional_concepts/authentication.html > > A quick search didn't yield more detailed instructions. Hopefully somebody > else chimes in. > > In the meantime, you can try things out by doing this: > 1. ssh to your cluster master > 2. find system:admin users's kubeconfig (/root/.kube/config or > /openshift.local.config/master/admin.kubeconfig are two common locations) > 3. this file is using certificate auth. You can inspect how it is done and > where the root CA is configured in > > > _______________________________________________ > users mailing list > [email protected] > http://lists.openshift.redhat.com/openshiftmm/listinfo/users >
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
