client certificate auth via common name

[roboll]

This is an initial proof of concept for implementing authentication using the common name on client certificates, as opposed to the current scheme which requires client certificates in conjunction with http basic authentication.

This is similar to the way kubernetes implements client authentication, using the common name on client certificates as a username.

There are two commits, the first is a small refactor to centralize the existing basic auth code, and the second is an initial implementation of pulling the client username from the certificate.

The approach looks like this:

• if an Authorization header exists on the request, do not check the certificate. proceed normally and check credentials.
• if the Authorization header is missing, attempt to extract the common name from the presented certificate and authenticate as the specified user (even if the user account specifies a password, the client certificate will bypass that and authenticate)

Wanted to get a bit of review and see if this was something you'd be interested in merging, if so, some considerations before merging..

• gate with a flag (it should be entirely backward compatible, so not sure if that's necessary)
• re-validate the certificate with the ca during authentication? (the authentication code uses the tls sessions validated chains, so as long as the tls config is set up with the ca properly, this should be unnecessary)
• limit user accounts that are accessible via client cert, and/or review the interop with basic auth
• documentation

[roboll]

Also need to consider how this will interact with proxy, which terminates the tls connection with the client and makes its own connection using different certs to the server.

[philips]

re-validate the certificate with the ca during authentication? (the authentication code uses the tls sessions validated chains, so as long as the tls config is set up with the ca properly, this should be unnecessary)

Can you explain this further? I don't follow.

Otherwise this seems good.

[roboll]

@philips sure.

Here I'm using the tls sessions's VerifiedChains, as opposed to PeerCertificates. The verified chains are the result of verification of the supplied peer certificates, verified by the tls transport. I'm making the assumption that we want to use the same verify options for authentication as are being used by the tls server to accept client certificates.

If, for example, we want to verify a specific key usage to allow client auth by common name to continue, we'd have to verify the certificates again in this block using the new VerifyOptions.

Since etcd is already accepting options at the server level to determine client certificate trust, I thought it made sense to piggy back on that rather than accepting (yet another) set of certificate validation flags.

[roboll]

@philips What are your thoughts on proxy authentication? right now this will not pass the user's certificate from the proxy back to the etcd cluster, so the proxy will be authenticated, not the user. Maybe that's acceptable if you assume etcd-proxy as a single tenant proxy, but with multiple consumers of a proxy they are all effectively sharing credentials.

[philips]

@roboll I think we need to change the proxy to be a L3 proxy. @xiang90 do we have an issue for this yet?

[ghodss]

Is there a reason this never got merged? etcd authz is basically broken right now since most applications can't tolerate the 100ms+ latency hit per request. This would very easily solve that issue and enable people to actually use etcd authz.

[xiang90]

@roboll @ghodss Sorry! We did not pay a lot attention to the v2 auth thing.

/cc @mitake Can you take a look at this pull request?

[mitake]

@xiang90 @ghodss @roboll sure, I'll look at it today. But this PR needs huge rebase. So I'd like to review the concept.

[mitake]

@roboll @ghodss @xiang90 the concept seems good to me. I think it can be merged after rebasing. The rebasing would be big but straightforward.

And I'm not sure how the problem of proxy is serious. Just making this feature and proxy mutually exclusive functionalities might be enough, I think. IIUC, v2 proxy is only for easy discovery so giving up the proxy would be not so serious for users who want this feature.

[ghodss]

Great to hear, @mitake. Is there any difference in how etcdv2 and etcdv3 handle authentication?

[mitake]

@ghodss yes, there is a big difference. For example, bcrypt password checking is required only when a client connects to servers. So I believe the 100ms+ latency per request can be avoided.

[ghodss]

Got it. In any case it would be great to avoid it altogether and enable us to not have to distribute passwords either.

[mitake]

@ghodss hashed password is replicated to every node of the cluster. Is this problem for you? It is required for enabling authentication on all nodes.

[ghodss]

That's fine - I meant more distributing the passwords to the etcd clients, and relying on common name instead.

[mitake]

@ghodss ah I see. v3 authentication doesn't support the auth based on common name yet. It would be worth to consider.

[xiang90]

@gyuho Can you try to cherry pick this patch set and resolve the conflicts?

[gyuho]

Closing in preference to #5991.

[qiujian16]

is there any document on how to use this feature?

[mitake]

@qiujian16 I'll add docs related to auth features. The issue is here: #7251
I'm finishing jwt token support for now. After it, I'll work on the doc.