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. |
You can use a TLS (Transport Layer Security) security profile, as described in this section, 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 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. |
In addition to cipher suites and minimum TLS version, TLS security profiles include a list of supported key exchange groups. Key exchange groups determine the cryptographic algorithm used during the TLS handshake to securely establish a shared session key between client and server.
The following key exchange groups are supported in OKD:
| Group | Description | ||
|---|---|---|---|
|
A post-quantum hybrid key encapsulation mechanism (KEM) that combines the post-quantum ML-KEM algorithm with the classical X25519 elliptic curve. This combination provides protection against both classical and quantum computing attacks.
|
||
|
A classical Diffie-Hellman key exchange using Curve25519, which provides strong security with good performance. Enabled by default in all predefined TLS profiles. |
||
|
An NIST P-256 elliptic curve Diffie-Hellman key exchange. Enabled by default in all predefined TLS profiles. |
||
|
An NIST P-384 elliptic curve Diffie-Hellman key exchange. Enabled by default in all predefined TLS profiles. |
|
To configure TLS ciphers and minimum versions for the kubelet HTTP server in OKD, apply a predefined or custom TLS security profile through a KubeletConfig custom resource (CR). Without a custom profile, the kubelet defaults to the Intermediate profile.
The following example is a KubeletConfig CR that configures the Old TLS security profile on worker nodes:
apiVersion: machineconfiguration.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.
You are logged in to OKD as a user with the cluster-admin role.
Create a KubeletConfig CR to configure the TLS security profile:
KubeletConfig CR for a Custom profileapiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
name: set-kubelet-tls-security-profile
spec:
tlsSecurityProfile:
type: Custom
custom:
ciphers:
- 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: ""
#...where:
spec.tlsSecurityProfile.typeSpecifies the TLS security profile type (Old, Intermediate, or Custom). The default is Intermediate.
spec.tlsSecurityProfile.type.customSpecifies the appropriate field for the selected type:
old: {}
intermediate: {}
modern: {}
custom:
spec.tlsSecurityProfile.type.customFor the custom type, specifies a list of TLS ciphers and the minimum accepted TLS version.
spec.machineConfigPoolSelector.matchLabels.customSpecifies the machine config pool label for the nodes you want to apply the TLS security profile. This parameter is optional.
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.
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 /hostView the kubelet.conf file:
sh-4.4# cat /etc/kubernetes/kubelet.conf "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",
#...