Not exactly a bug, it's a question regarding Security. about k0sctl HOT 3 CLOSED

I am assuming behind the scenes somewhere k0sctl uses tokens for node registration.

K0sctl uses k0s's own mechanism to create join tokens for additional nodes.

1. For each additional node k0sctl generates a join token using k0s token create --role=XX --expiry 10m on the first controller node.
2. This token is copied to the other node's /etc/k0s/k0stoken.
3. K0s is installed and started on the other node, which will use the join token for authenticating the node to the k0s/k8s cluster.
4. Once the node has joined the cluster, k0sctl uses k0s token invalidate to invalidate the token and removes the key from /etc/k0s/k0stoken as it is not needed anymore. This will also be done if the installation fails to avoid leaving behind unused tokens.

If a control plane is compromised, will that mean all the SSH keys to worker nodes will be compromised ??

The nodes in your cluster don't require SSH access to each other. K0sctl is primarily used from your workstation or a deployment system and isn't actually installed on the cluster itself. It's intended for use by individuals or systems with administrative-level SSH access to the nodes. K0s doesn't need or utilize k0sctl and you don't need k0sctl to manage k0s – it's a separate optional utility for simplified k0s deployments.

SSH Access: The tool needs SSH access to the nodes. If the SSH keys or credentials are mishandled or stored insecurely, unauthorized users could gain access to your nodes.

This principle applies universally to systems with any form of authentication. Avoid mishandling or insecure storage of credentials.

Permission Level: Typically, administrative or root-level access is required to perform many of the operations. If an attacker gains control of the tool or the system where it's run, they could potentially execute arbitrary commands on your nodes.

Using passphrase-encrypted SSH keys adds an extra layer of protection against potential breach if your local system were to be compromised.

Man-in-the-Middle Attacks: If SSH is not configured to use strong encryption and authentication, there could be potential for man-in-the-middle attacks, where an attacker intercepts and possibly alters the communication between the tool and the nodes.
Lack of Network Segmentation: If SSH is open to the world and not restricted to specific IP addresses or networks, it increases the attack surface.
Automation Risks: Automated tools that perform complex tasks can sometimes introduce unexpected security holes, depending on how they are configured and used.
Are the above concerns handled by k0sctl behind the scenes?

Configuring SSH and network security falls outside k0sctl's scope.

from k0sctl.

Hi

@twz123 thank you for assigning the right labels.
@kke Thank you very much for clarifications. It explains a lot clearly of whats happening in background.

Once the node has joined the cluster, k0sctl uses k0s token invalidate to invalidate the token and removes the key from /etc/k0s/k0stoken as it is not needed anymore. This will also be done if the installation fails to avoid leaving behind unused tokens.

I just have 1 question left. So if the token is invalidated. Say in future, If the node changed its Ip address due to some reason. Will that node still be able to register itself with the control plane. I am specifically looking for node registration for nodes that can have dynamic IP.

from k0sctl.

After the initial join, the workers continue to communicate with the cluster using x509 client certificates through the kube api. The controllers do not directly communicate with the workers.

In kubelet there's:

--hostname-override string
  If non-empty, will use this string as identification instead of the actual hostname. If --cloud-provider is set, the cloud provider determines the name of the node (consult cloud provider documentation to determine if and how the hostname is used).

K0sctl already validates that every node has a unique hostname, so I think it may just work even without --cloud-provider, but I'm not sure, as k0sctl does set the --node-ip when joining workers:

--node-ip string
IP address (or comma-separated dual-stack IP addresses) of the node. If unset, kubelet will use the node's default IPv4 address, if any, or its default IPv6 address if it has no IPv4 addresses. You can pass '::' to make it prefer the default IPv6 address rather than the default IPv4 address.

Anyway, just recording api communication and reusing an existing worker's IP won't allow a rogue node to communicate with the control plane, as it needs the client cert private key from the real worker.

from k0sctl.