Enabling TLS security profiles for the kubelet
You can use a TLS (Transport Layer Security) security profile to define which TLS ciphers are required by the kubelet when it is acting as an HTTP server. The kubelet uses its HTTP/GRPC server to communicate with the Kubernetes API server, which sends commands to pods, gathers logs, and run exec commands on pods through 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.
By default, when the kubelet acts as a client with the Kubernetes API server, it automatically negotiates the TLS parameters with the API server. |
Understanding TLS security profiles
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:
Profile | Description | ||||
---|---|---|---|---|---|
| This profile is intended for use with legacy clients or libraries. The profile is based on the Old backward compatibility recommended configuration. The
| ||||
| 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 | ||||
| This profile is intended for use with modern clients that have no need for backwards compatibility. This profile is based on the Modern compatibility recommended configuration. The
| ||||
| This profile allows you to define the TLS version and ciphers to use.
|
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
apiVersion: config.openshift.io/v1
kind: KubeletConfig
...
spec:
tlsSecurityProfile:
old: {}
type: Old
machineConfigPoolSelector:
matchLabels:
pools.operator.machineconfiguration.openshift.io/worker: ""
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 The kubelet also converts the TLS |
Prerequisites
- You have access to the cluster as a user with the
cluster-admin
role.
Procedure
Create a
KubeletConfig
CR to configure the TLS security profile:Sample
KubeletConfig
CR for aCustom
profileapiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
name: set-kubelet-tls-security-profile
spec:
tlsSecurityProfile:
type: Custom (1)
custom: (2)
ciphers: (3)
- ECDHE-ECDSA-CHACHA20-POLY1305
- ECDHE-RSA-CHACHA20-POLY1305
- ECDHE-RSA-AES128-GCM-SHA256
- ECDHE-ECDSA-AES128-GCM-SHA256
minTLSVersion: VersionTLS11
machineConfigPoolSelector:
matchLabels:
pools.operator.machineconfiguration.openshift.io/worker: "" (4)
1 Specify the TLS security profile type ( Old
,Intermediate
, orCustom
). The default isIntermediate
.2 Specify the appropriate field for the selected type: old: {}
intermediate: {}
custom:
3 For the custom
type, specify a list of TLS ciphers and minimum accepted TLS version.4 Optional: Specify the machine config pool label for the nodes you want to apply the TLS security profile. Create the
KubeletConfig
object:$ oc create -f <filename>
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:
Start a debug session for a configured node:
$ oc debug node/<node_name>
Set
/host
as the root directory within the debug shell:sh-4.4# chroot /host
View the
kubelet.conf
file:sh-4.4# cat /etc/kubernetes/kubelet.conf
Example output
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
...
"tlsCipherSuites": [
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
"TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"
],
"tlsMinVersion": "VersionTLS12",