Open dragonly opened 3 years ago
@AstroProfundis @tennix Could you please share some information on why we changed from the operator managed TLS solution to the current solution last year?
Some reasons that changed from the operator managed TLS solution to the current solution:
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?
@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
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.