Communication between Nodes and the Control Plane

    Kubernetes has a “hub-and-spoke” API pattern. All API usage from nodes (or the pods they run) terminates at the API server. None of the other control plane components are designed to expose remote services. The API server is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client enabled. One or more forms of authorization should be enabled, especially if or service account tokens are allowed.

    Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the API server along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See for automated provisioning of kubelet client certificates.

    Pods that wish to connect to the API server can do so securely by leveraging a service account so that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated. The service (in default namespace) is configured with a virtual IP address that is redirected (via ) to the HTTPS endpoint on the API server.

    The control plane components also communicate with the API server over the secure port.

    As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks.

    Control plane to node

    The connections from the API server to the kubelet are used for:

    • Fetching logs for pods.
    • Attaching (usually through kubectl) to running pods.

    These connections terminate at the kubelet’s HTTPS endpoint. By default, the API server does not verify the kubelet’s serving certificate, which makes the connection subject to man-in-the-middle attacks and unsafe to run over untrusted and/or public networks.

    To verify this connection, use the flag to provide the API server with a root certificate bundle to use to verify the kubelet’s serving certificate.

    If that is not possible, use SSH tunneling between the API server and kubelet if required to avoid connecting over an untrusted or public network.

    Finally, should be enabled to secure the kubelet API.

    Kubernetes supports SSH tunnels to protect the control plane to nodes communication paths. In this configuration, the API server initiates an SSH tunnel to each node in the cluster (connecting to the SSH server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or service through the tunnel. This tunnel ensures that the traffic is not exposed outside of the network in which the nodes are running.

    Note: SSH tunnels are currently deprecated, so you shouldn’t opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel.

    FEATURE STATE:

    As a replacement to the SSH tunnels, the Konnectivity service provides TCP level proxy for the control plane to cluster communication. The Konnectivity service consists of two parts: the Konnectivity server in the control plane network and the Konnectivity agents in the nodes network. The Konnectivity agents initiate connections to the Konnectivity server and maintain the network connections. After enabling the Konnectivity service, all control plane to nodes traffic goes through these connections.

    Follow the Konnectivity service task to set up the Konnectivity service in your cluster.