Excuse me for the ignorance, but how about PKI *without* a proxy layer? Wouldn't that allow flexibility with lower complexity?Jordan Liggitt wrote on 02/20/2016 01:30 AM:
On Feb 19, 2016, at 5:48 PM, Aleksandar Kostadinov <akostadi redhat com> wrote:
Jordan Liggitt wrote on 02/20/2016 12:07 AM:
The configurations listed at
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
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.
Certificate revocations can be handled by OCSP?