Enabling TLS security profiles for the kubelet

    A TLS security profile defines the TLS ciphers that the Kubernetes API server must use when connecting with the kubelet to protect communication between the kubelet and the Kubernetes API server.

    You can use a TLS (Transport Layer Security) security profile to define which TLS ciphers are required by various OKD components. The OKD TLS security profiles are based on Mozilla recommended configurations.

    You can specify one of the following TLS security profiles for each component:

    Table 1. TLS security profiles
    ProfileDescription

    This profile is intended for use with legacy clients or libraries. The profile is based on the recommended configuration.

    The Old profile requires a minimum TLS version of 1.0.

    For the Ingress Controller, the minimum TLS version is converted from 1.0 to 1.1.

    Intermediate

    This profile is the recommended configuration for the majority of clients. It is the default TLS security profile for the Ingress Controller, kubelet, and control plane. The profile is based on the Intermediate compatibility recommended configuration.

    The Intermediate profile requires a minimum TLS version of 1.2.

    Modern

    This profile is intended for use with modern clients that have no need for backwards compatibility. This profile is based on the recommended configuration.

    The Modern profile is currently not supported.

    Custom

    This profile allows you to define the TLS version and ciphers to use.

    Use caution when using a Custom profile, because invalid configurations can cause problems.

    When using one of the predefined profile types, the effective profile configuration is subject to change between releases. For example, given a specification to use the Intermediate profile deployed on release X.Y.Z, an upgrade to release X.Y.Z+1 might cause a new profile configuration to be applied, resulting in a rollout.

    Configuring the TLS security profile for the kubelet

    To configure a TLS security profile for the kubelet when it is acting as an HTTP server, create a KubeletConfig custom resource (CR) to specify a predefined or custom TLS security profile for specific nodes. If a TLS security profile is not configured, the default TLS security profile is Intermediate.

    Sample KubeletConfig CR that configures the Old TLS security profile on worker nodes

    You can see the ciphers and the minimum TLS version of the configured TLS security profile in the kubelet.conf file on a configured node.

    The kubelet does not support TLS 1.3 and because the Modern profile requires TLS 1.3, it is not supported. The kubelet converts the profile to Intermediate.

    The kubelet also converts the TLS 1.0 of an Old or Custom profile to 1.1, and TLS 1.3 of a Custom profile to 1.2.

    Prerequisites

    • You have access to the cluster as a user with the cluster-admin role.
    1. Create a KubeletConfig CR to configure the TLS security profile:

      Sample KubeletConfig CR for a Custom profile

      1. apiVersion: machineconfiguration.openshift.io/v1
      2. kind: KubeletConfig
      3. metadata:
      4. name: set-kubelet-tls-security-profile
      5. spec:
      6. type: Custom (1)
      7. custom: (2)
      8. ciphers: (3)
      9. - ECDHE-RSA-CHACHA20-POLY1305
      10. - ECDHE-RSA-AES128-GCM-SHA256
      11. - ECDHE-ECDSA-AES128-GCM-SHA256
      12. minTLSVersion: VersionTLS11
      13. machineConfigPoolSelector:
      14. pools.operator.machineconfiguration.openshift.io/worker: "" (4)
    2. Create the KubeletConfig object:

      Depending on the number of worker nodes in the cluster, wait for the configured nodes to be rebooted one by one.

    Verification

    To verify that the profile is set, perform the following steps after the nodes are in the Ready state:

    1. Start a debug session for a configured node:

      1. $ oc debug node/<node_name>
    2. Set /host as the root directory within the debug shell:

    3. View the kubelet.conf file:

        Example output