Description
What would you like to be added?
https://etcd.io/docs/v3.5/op-guide/security/ says the following about the --peer-cert-allowed-cn flag (emphasis mine):
v3.3.0 adds etcd --peer-cert-allowed-cn flag to support CN(Common Name)-based auth for inter-peer connections. Kubernetes TLS bootstrapping involves generating dynamic certificates for etcd members and other system components (e.g. API server, kubelet, etc.). Maintaining different CAs for each component provides tighter access control to etcd cluster but often tedious. When --peer-cert-allowed-cn flag is specified, node can only join with matching common name even with shared CAs. For example, each member in 3-node cluster is set up with CSRs (with cfssl) as below:
The example provided below (m1.etcd.local matches etcd.local, not m2.etcd.local seems to suggests something like "is a subdomain of" match, but it's not specified explicitly (at least I didn't found it).
https://etcd.io/docs/v3.5/op-guide/configuration/#security reads to me instead as it should be an exact match.
Could the match function/method used be explicitly called out ?
I presume the same matching mechanisms apply to --peer-cert-allowed-hostname (use SAN instead of CN if I'm correct) and --client-cert-allowed-hostname
Why is this needed?
Easier locking down of an etcd cluster
/area documentation