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: prevent bootstrap of nodes with known names #81056
kubeadm: prevent bootstrap of nodes with known names #81056
Conversation
[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 |
what are the implications for cleaning up a node to set it up again? does this mean that |
klog.V(1).Infof("[kubelet-start] Checking for an existing node with name %q in the cluster", nodeName) | ||
nodes, err := bootstrapClient.CoreV1().Nodes().List(metav1.ListOptions{}) | ||
if err != nil { | ||
return errors.Wrap(err, "cannot obtain the list of nodes in the cluster") |
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.
should this be a skippable preflight check instead?
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.
+1 on that, we need to be able to skip this as I can see users running into problems with stale nodes, etc.
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.
no so sure about this, stale nodes are a subject of the administrator calling kubectl delete
. kubeadm join
failing during boostrap would indicate that the cluster requires admin intervetion (or node rename).
if the user is allowed to skip this check, it can lead to catastrophic outcome - e.g. imaging a case where the operator responsible for the worker join is not the cluster admin.
let's talk more about this during the office hours, possibly next week.
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.
Thanks @neolit123 !
We may also try to nuke the Node object on reset, but permission wise IDK if this is feasible.
klog.V(1).Infof("[kubelet-start] Checking for an existing node with name %q in the cluster", nodeName) | ||
nodes, err := bootstrapClient.CoreV1().Nodes().List(metav1.ListOptions{}) | ||
if err != nil { | ||
return errors.Wrap(err, "cannot obtain the list of nodes in the cluster") |
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.
+1 on that, we need to be able to skip this as I can see users running into problems with stale nodes, etc.
if
Get is way more efficient on large clusters. A bootstrap token can obtain a node client credential that allows get/list/watch of all nodes, so read-only access to Get a node is not concerning. |
completely forgot about
possibly a separate PR, but also needs permission evaluation. |
this is a problem that i though about after sending the PR. we either have to:
|
6e4e38a
to
1f078d6
Compare
8759416
to
43b1316
Compare
i have updated this PR:
|
27ea933
to
e52a155
Compare
/retest |
/test pull-kubernetes-kubemark-e2e-gce-big |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
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.
Thanks @neolit123 !
Implementation wise, it looks good.
We may want to add a more thorough message to the user along with steps how to fix the problem.
/lgtm
If a Node name in the cluster is already taken and this Node is Ready, prevent TLS bootsrap on "kubeadm join" and exit early. This change requires that a new ClusterRole is granted to the "system:bootstrappers:kubeadm:default-node-token" group to be able get Nodes in the cluster. The same group already has access to obtain objects such as the KubeletConfiguration and kubeadm's ClusterConfiguration. The motivation of this change is to prevent undefined behavior and the potential control-plane breakdown if such a cluster is racing to have two nodes with the same name for long periods of time. The following values are validated in the following precedence from lower to higher: - actual hostname - NodeRegistration.Name (or "--node-name") from JoinConfiguration - "--hostname-override" passed via kubeletExtraArgs If the user decides to not let kubeadm know about a custom node name and to instead override the hostname from a kubelet systemd unit file, kubeadm will not be able to detect the problem.
e52a155
to
b117a92
Compare
/hold cancel |
/retest |
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.
Thanks @neolit123 !
/lgtm
/retest Review the full test history for this PR. Silence the bot with an |
/test pull-kubernetes-e2e-gce |
/retest Review the full test history for this PR. Silence the bot with an |
2 similar comments
/retest Review the full test history for this PR. Silence the bot with an |
/retest Review the full test history for this PR. Silence the bot with an |
What this PR does / why we need it:
If a Node name in the cluster is already taken and this Node is Ready,
prevent TLS bootsrap on "kubeadm join" and exit early.
This change requires that a new ClusterRole is granted to the
"system:bootstrappers:kubeadm:default-node-token" group to be
able get Nodes in the cluster. The same group already has access
to obtain objects such as the KubeletConfiguration and kubeadm's
ClusterConfiguration.
The motivation of this change is to prevent undefined behavior
and the potential control-plane breakdown if such a cluster
is racing to have two nodes with the same name for long periods
of time.
The following values are validated in the following precedence
from lower to higher:
If the user decides to not let kubeadm know about a custom node name
and to instead override the hostname from a kubelet systemd unit file,
kubeadm will not be able to detect the problem.
Which issue(s) this PR fixes:
Fixes kubernetes/kubeadm#1711
Special notes for your reviewer:
NONE
Does this PR introduce a user-facing change?:
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:
/kind feature
/priority important-longterm