On Mon, Feb 22, 2016 at 2:20 AM, Aleksandar Kostadinov <[email protected]> wrote:
> Jordan Liggitt wrote on 02/20/2016 01:30 AM: > >> On Feb 19, 2016, at 5:48 PM, Aleksandar Kostadinov <[email protected]> >>> wrote: >>> >>> Jordan Liggitt wrote on 02/20/2016 12:07 AM: >>> >>>> 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. >>>> >>> >>> But with proper kubeconfig (certificates in there), you don't ever need >>> to obtain a token, correct? This is what I am observing. >>> >>> >> 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. > Certificate revocations can be handled by OCSP? > I haven't worked with OCSP for client certs... is stapling supported?
_______________________________________________ users mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
