client/pkg/transport: Support multiple values for allowed client and peer TLS identities

[LINKIWI]

This change proposes allowing multiple CNs or SAN DNS names for client and peer TLS verification. This is useful for use cases that depend on etcd to enforce an ACL, but where there are multiple different clients (with different certificates and thus different identities) permitted to connect to the cluster.

The proposal is to use a comma as the delimiting character for multiple allowed identities. The peer verification routine allows the handshake to proceed as long as the peer identity matches one of the supplied allowed identities.

Note that in f1500fb I changed the type of AllowedCN and AllowedHostname in TLSInfo to a []string to accommodate this, and pulled out the comma-separated list parsing to the command line parser. However, this breaks backwards compatibility for embedded etcd users. If desired, I can leave AllowedCN and AllowedHostname as strings (to retain backwards compatibility) and instead do a strings.Split in the verifyCertificate routine itself.

Tangentially related change: #13445.

Closes #11728.

[mitake]

@LINKIWI I think the change seems to be reasonable, but could you share some additional motivations for doing this for peer connection? It’s still not clear for me so I want to understand concrete use cases.

[LINKIWI]

Hi @mitake the primary motivation for this change (in general) is to allow etcd to enforce server ACLs with multi-valued identities. For peer verification/intra-cluster traffic in particular, using CN validation as an example, this would allow identity enforcement for connections of all other peer members, all of whom have unique CNs.

It is common for each node within the same cluster to have unique CNs (usually the machine hostname). Currently, I don't think there exists a mechanism to support such a peer ACL natively in etcd without this patch. (Another commonly implemented approach is supporting prefix or regular expression matches)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.