-
Notifications
You must be signed in to change notification settings - Fork 499
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
Auto generate and sign certificates for TLS enabled cluster #782
Conversation
It can be problematic to automatically create the cert if the secret is not found: the deployer may have forgotten that step. It may be better to more explicitly configure the cert source. |
8a09d7f
to
56627d0
Compare
@gregwebs We can check if a csr already exist and try to approve that, but we don't have private key in that situation, I haven't came up with any idea good enough to check if user had forgotten to create secret (or mis-configured the secret), or there is no pre-confiugred key pair at all. Any suggestions? BTW, I think our current procedure don't support user generated certs, supporting custom cert would need to support external CA as well, this won't work with this PR at present. |
The approach would be to explicitly configure whether a secret is expected. If it is expected and does not exist, than that produces an error. |
/run-e2e-in-kind |
/run-e2e-in-kind |
The |
@@ -11,7 +11,7 @@ detect-interval = {{ .Values.binlog.drainer.detectInterval | default 10 }} | |||
data-dir = "/data" | |||
|
|||
# a comma separated list of PD endpoints | |||
pd-urls = "http://{{ template "cluster.name" . }}-pd:2379" | |||
pd-urls = "{{ if .Values.enableTLSCluster }}https{{ else }}http{{ end }}://{{ template "cluster.name" . }}-pd:2379" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can define a SCHEME
macro in _helpers.tpl
to avoid repeating the if-else
block again and again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
/run-e2e-in-kind |
1 similar comment
/run-e2e-in-kind |
/run-e2e-in-kind |
/run-e2e-in-kind |
What problem does this PR solve?
Automatically generate and sign certificates for TLS enabled TiDB clusters, if:
Secret
matching the name and labels, andCertificateSigningRequest
matching the name that not matching the labels (so that they are not created by us)After certificates get automatically approved, they are stored as Secrets and mount to Pods.
The procedure is based on the manual for ansible deployment.
The corresponding documents are here:
What is changed and how does it work?
This PR includes and close #750 and added controllers to handle certificate managements.
Check List
Tests
Manually validated on internal testing k8s cluster.
Code changes
Known Issues
v3.0.5
Related changes
#750
Does this PR introduce a user-facing change?: