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
kubeadm: validate local etcd certficates during expiration checks #106891
kubeadm: validate local etcd certficates during expiration checks #106891
Conversation
In case stacked etcd is used, the code that does expiration checks does not validate if the etcd CA is "external" (missing key) and if the etcd CA signed certificates are valid. Add a new function UsingExternalEtcdCA() similar to existing functions for the cluster CA and front-proxy CA, that performs the checks for missing etcd CA key and certificate validity. This function only runs for stacked etcd, since if etcd is external kubeadm does not track any certs signed by that etcd CA. This fixes a bug where the etcd CA will be reported as local even if the etcd/ca.key is missing during "certs check-expiration".
Apply a small fix to ensure the kubeconfig files that kubeadm manages have a CA when printed in the table of the "check expiration" command. "CAName" is the field used for that. In practice kubeconfig files can contain multiple credentials from different CAs, but this is not supported by kubeadm and there is a single cluster CA that signs the single client cert/key in kubeadm managed kubeconfigs.
/triage accepted |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: neolit123 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
It works fine. [check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED
admin.conf Nov 06, 2022 10:59 UTC 332d ca no
apiserver Nov 06, 2022 10:59 UTC 332d ca no
apiserver-etcd-client Nov 06, 2022 10:59 UTC 332d etcd-ca yes
apiserver-kubelet-client Nov 06, 2022 10:59 UTC 332d ca no
controller-manager.conf Nov 06, 2022 10:59 UTC 332d ca no
etcd-healthcheck-client Nov 06, 2022 10:59 UTC 332d etcd-ca yes
etcd-peer Nov 06, 2022 10:59 UTC 332d etcd-ca yes
etcd-server Nov 06, 2022 10:59 UTC 332d etcd-ca yes
front-proxy-client Nov 06, 2022 10:59 UTC 332d front-proxy-ca no
scheduler.conf Nov 06, 2022 10:59 UTC 332d ca no
CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
ca Nov 04, 2031 10:59 UTC 9y no
etcd-ca Nov 04, 2031 10:59 UTC 9y yes
front-proxy-ca Nov 04, 2031 10:59 UTC 9y no |
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
We can also cherry-pick this to the previous versions after it is merged. |
The Kubernetes project has merge-blocking tests that are currently too flaky to consistently pass. This bot retests PRs for certain kubernetes repos according to the following rules:
You can:
/retest |
…06891-origin-release-1.23 Automated cherry pick of #106891: kubeadm: validate local etcd certficates during
…06891-origin-release-1.21 Automated cherry pick of #106891: kubeadm: validate local etcd certficates during
…06891-origin-release-1.22 Automated cherry pick of #106891: kubeadm: validate local etcd certficates during
…06891-origin-release-1.20 Automated cherry pick of #106891: kubeadm: validate local etcd certficates during
What type of PR is this?
/kind bug
What this PR does / why we need it:
this second commit is a cleanup on the side...
Which issue(s) this PR fixes:
xref kubernetes/kubeadm#2618 (comment)
xref kubernetes/kubeadm#2618
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: