-
Notifications
You must be signed in to change notification settings - Fork 500
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TiDB cluster TLS not work on EKS #1685
Comments
A workaround to this could be to bake authentication/identity information into the certificate's subject instead of its SAN. |
Created a cluster with the following,
The PDs failed to start:
The configuration file is empty:
|
I followed this commit: cloudfoundry-incubator/quarks-operator@cbab593 to change
But that doesn't work either.
|
I didn't understand how their workaround worked either... Maybe the cf-operator has a fallback or something that if the DNS doesn't pass validation it'll try again with the |
TLS authentication includes the following two conditions:
We have supported the second condition with the user-defined certificate: #1714 To solve the first conditions on EKS, we may also support TiDB components mutual authentication using user-defined certificates, like #1714 does. What's your opinion? @tennix @mightyguava @cofyc |
I think it is good to support user-specified certificates. |
Yes, I suggest using cert-manager to support automatic certificate management which can support different kinds of CA. See #1669 |
User-defined certificates is different from cert-manager issued certificates. If we use cert-manager, the CA Private Key must be provided. User-defined certificate doesn't need the CA Private Key, just certificates. For this EKS problem, we just used user-defined certificate to resolve this problem. cert-manger needs a lot of refactor, but still cannot using user-defined certificates. |
we can have a manual way to configure certificate first, then we can use cert-manager to provision certificate and configure it in TidbCluster CRD automatically. |
Yes, for first step, we can support user generate certificates manually for the internal mutual TLS. Though the operation is verbose, it can work. Then I think we need to support cert-manager anyway, because on some platforms users need to automate the procedure and auto rotate certificates before the certificates get expired. |
We definitely prefer having the operator manage the certs for us than doing manual user-defined certificates. Cert manager seems like a good option too, but in that case we would want to be able to use AWS Private CA rather than providing cert manager with the private key. There's an open PR here cert-manager/cert-manager#2302 In the meanwhile, is it still possible to have a workaround on EKS that allows us to use the Kubernetes CA? |
First we need to support user-defined certificates to let EKS work properly. At the same time we should try to find other possible workarounds on EKS. In the long run, we still need to support cert-manger to issue certificate, if the AWS Private CA feature is ready, we can use it too. |
EKS might fix this: aws/containers-roadmap#750 |
We've already fixed this by allowing users provide a TLS secret themselves. The TLS secret can be created by cert-manager or by public CA signed certificates. |
Bug Report
The EKS generated certificate Subject only contains
Subject: O=PingCAP, OU=TiDB Operator, CN=tls-cluster-pd
and noSAN
(-pd-1.-pd-peer..svc), thus causing the cluster failed to bootstrap. The detailed PD log is as follows:There is a similar issue here awslabs/amazon-eks-ami#341. And cloudfoundry-operator uses a workaround approach: cloudfoundry-incubator/quarks-operator@cbab593
This bug can be reproduced in 1.12 ~ 1.14(current latest). We should consider adopting the similar workaround approach as cf-operator.
The text was updated successfully, but these errors were encountered: