Support multiple values for allowed client and peer TLS identities

[lhy1024]

Please read https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#contribution-flow.

From #13460

We also need the similiar features, and hope etcd can support multiple values for allowed client. Ref tikv/pd#5134

[k8s-ci-robot]

Hi @lhy1024. Thanks for your PR.

I'm waiting for a etcd-io member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[jmhbnz]

Hi @lhy1024 - Thanks for proposing this. It looks like some of the commits are not signed. Can you please take a look and ensure all commits are signed so the developer certificate of origin check passes?

In this case it may involve changing author or re-doing some of the commits to ensure you can sign them off.

[jmhbnz]

/ok-to-test

[lhy1024]

/test pull-etcd-e2e-amd64

[lhy1024]

/retest-required

[lhy1024]

/retest

[lhy1024]

/test pull-etcd-e2e-amd64

[lhy1024]

/test pull-etcd-unit-test

[lhy1024]

/retest-required

[lhy1024]

@jmhbnz PTAL.

BTW, could this pr be picked to 3.5 or 3.4?

[jmhbnz]

Thanks for resurrecting this @lhy1024. I think it would be helpful if you could expand on your reasons/motivations for wanting this in the pr description so the why is clear.

Overall I think the changes themselves seem reasonable, besides the potential breaking change decision mentioned below. However to set expectations given this is TLS we need wider careful review which can take a while.

cc @ahrtr, @serathius to please also take a look at this.

[lhy1024]

Thanks for resurrecting this @lhy1024. I think it would be helpful if you could expand on your reasons/motivations for wanting this in the pr description so the why is clear.

Overall I think the changes themselves seem reasonable, besides the potential breaking change decision mentioned below. However to set expectations given this is TLS we need wider careful review which can take a while.

cc @ahrtr, @serathius to please also take a look at this.

I am part of the team at PingCAP, a company dedicated to open-source database solutions. Our database comprises three core components: TiDB, TiKV, and PD. Currently, we are working to enhance our database's capabilities by supporting multiple CNs for SSL/TLS certificates, which is crucial for many of our users' security configurations.

However, we've encountered a limitation with PD, which relies on an embedded etcd. Unfortunately, etcd does not currently support multiple CNs, which has prompted the need for this pull request. By merging this PR, we aim to overcome this limitation, thereby aligning TiDB with the security flexibility required by modern distributed systems.

Additionally, I noticed that Datadog, another prominent player in the industry, has also implemented a similar feature by picking old PRs for their fork. This observation suggests that there is a broader demand for such a feature, indicating its potential utility and impact within the community.

Given the nature of this update and its implications on TLS configurations, I understand and appreciate the need for a thorough and careful review process. I look forward to the feedback from the community and thank you in advance for your careful consideration.

[lhy1024]

PTAL @jmhbnz