Clarify what "match" means for `--*-cert-allowed-{cn/hostname}` flags

[VannTen]

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

[k8s-ci-robot]

@VannTen: The label(s) area/documentation cannot be applied, because the repository doesn't have them.

In response to this:

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

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[jberkus]

Next steps: can someone test what the actual behavior is here so we know where to correct the docs.

[ronaldngounou]

Good to close @jberkus @nate-double-u

[VannTen]

I don't think the linked PR is enough to close this, as the wording it still the same (implicit) in https://etcd.io/docs/v3.7/op-guide/security/#notes-for-tls-authentication

[ronaldngounou]

Good catch. I am going to send a PR for it unless you want to.

[VannTen]

Go ahead, it's on my TODO list, but since that list is very long, it's probable I won't get to it any time soon ^^