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.
_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
