User friendly TLS management mechanism

[dragonly]

Feature Request

A more user friendly TLS management mechanism.

Is your feature request related to a problem? Please describe:

Now TiDB Operator supports enabling TLS between cluster components and TLS for MySQL clients, which is basically enough.

But the current feature requires users to manually generate/manage CA and all sorts of certs/configs, which will easily become a mess in real-world production scenario.

Moreover, it's now very troublesome to rotate the server certs when it's near to expiration. Manually rotating certs requires careful operations and rolling updates, and any human mistake can take down the whole cluster, which will make service unavailable.

Describe the feature you'd like:

An all-managed-by-operator way of using TLS in TiDB clusters.
Users can also turn this off and manually manage the TLS certs.

Describe alternatives you've considered:

Manual management as in the current situation, which is BAD.

Teachability, Documentation, Adoption, Migration Strategy:

TBD.

[DanielZhangQD]

@AstroProfundis @tennix Could you please share some information on why we changed from the operator managed TLS solution to the current solution last year?

[DanielZhangQD]

Some reasons that changed from the operator managed TLS solution to the current solution:

• Some users want to use their own certificates, and they can use self-managed or commercial CA
• There is a problem with the certificate signed by eks TiDB cluster TLS not work on EKS #1685
• If the certificates signed by a k8s cluster share the same CA, any certificate signed in that k8s can connect to the TiDB cluster if CN is not required, which is not safe.

[tennix]

Moreover, it's now very troublesome to rotate the server certs when it's near to expiration. Manually rotating certs requires careful operations and rolling updates, and any human mistake can take down the whole cluster, which will make service unavailable.

@dragonly Have you tried using cert-manager? It nearly becomes the defacto certificate management tool in k8s world. It can rotate certificates automatically before expiration.

An all-managed-by-operator way of using TLS in TiDB clusters.

How should tidb-operator manage the certificates? Using cert-manager or the k8s builtin CA to sign certificate?

Besides, are there any users requesting this feature or just our own pain point for testing when developing tidb-operator?

[dragonly]

@tennix

Have you tried using cert-manager? It nearly becomes the defacto certificate management tool in k8s world. It can rotate certificates automatically before expiration.

Yes, and I am not saying that we should do this in TiDB Operator, but call/use cert-manager to do the hard work.

How should tidb-operator manage the certificates? Using cert-manager or the k8s builtin CA to sign certificate?

One possible solution is to utilize cert-manager.

Besides, are there any users requesting this feature or just our own pain point for testing when developing tidb-operator?

Currently this is not a user request, so I just want to post an issue and gather some thoughts about the TLS management feature.
For the development, we can add some handy hack scripts for now