Require a specific cert CN from peer client certificate

[ericchiang]

When turning on Kubernetes TLS bootstrapping, we'd like to generate dynamic peer client certs for etcd members, but only want to maintain a single CA per cluster (the CSR API doesn't handle multiple CAs well). We're going to be granting client certificates to other things in the system (the API server, kubelet, etc) and don't want them to be able to talk to the etcd peer API.

We can already restrict the client API using the certificate CN, we'd like to be able to do the same thing for the peer API. Something like this:

--peer-cert-allowed-cn="etcd-member"

which would require the client certs to have that exact CN.

Alternatives might be something more dynamic, such as having each etcd peer have a different CN. But since the etcd members use the peer API to join the cluster, it's unclear how we would update that list. Would you use the client API?

You also can't specify an etcd member's name beforehand (this is an intentional choice) so schemes like etcd-member:(member name) won't work either.

cc @luxas I think we hit a similar issue to you.
cc @heyitsanthony

[luxas]

Very interested in how this turns out... playing with different alternative implementations right now...
Would be great to make etcd clustering easier/more dynamic

[heyitsanthony]

Alternatives might be something more dynamic, such as having each etcd peer have a different CN.

Would IP/DNS SAN be enough to bind the cert to a peer? Certs can be banned via CRLs and the certs could expire within some reasonable timeframe to keep the CRL from growing indefinitely.

The basic user-tunable peer CN flag would be very easy add to etcd.

[ericchiang]

Would IP/DNS SAN be enough to bind the cert to a peer? Certs can be banned via CRLs and the certs could expire within some reasonable timeframe to keep the CRL from growing indefinitely.

IP/DNS SAN values don't have much value in client certs, do they? Are you suggesting something like the client having to have send traffic through an originating IP that its client cert is signed for?

I feel like the CRLs point is a different feature. Even if we don't add an auth-Z mechanism to the peer API, we could still talk about credential revocation through CRLs.

[heyitsanthony]

@ericchiang etcd peer listeners already check CRLs and SAN values for incoming connections when given. I'd like to avoid having an additional authentication mechanism if everything can already be done via certs...

[ericchiang]

Is there a way to require a SANs value? That might be enough. Let me see if there's some platform agnostic way to get the expected IP of the etcd node in our setup.

[heyitsanthony]

@ericchiang yes.

[rmb938]

I would also like to have this ability. Being able to use the same CA for client and peer certs while requiring peer certificate CNs to match exactly or using regex would make deployment and management easier.

[gyuho]

This should be covered by #8616.

[luxas]

@ericchiang Happy with the implementation?

[ericchiang]

@luxas yep. This works for me.