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

Re: Multi Clusters : Token management

On Mon, Feb 22, 2016 at 2:20 AM, Aleksandar Kostadinov <akostadi redhat com> wrote:
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.

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?


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