Translated message

A translation of this page exists in English.

OpenShift Container Platform 中的 TLS 配置

已更新 -

免责声明：这里包含的到外部网站的链接仅供方便之用。红帽没有审查链接，不负责内容或其可用性。包含到外部网站的任何链接并不意味着红帽认可该网站或其实体、产品或服务。您同意，红帽不承担由于您使用（或依赖）外部网站或内容而导致的任何损失或费用的责任。

简介

此文档旨在作为 OpenShift Container Platform 3 和 4 中 TLS 配置选项的比较和概述。在可能的情况下，建议使用最新版本的 TLS 1.3。

TLS 1.3 是 TLS 规范的一个重要的新版本，它包括了对握手协议的重大变化，大大提高了性能和安全。对于某些 OpenShift 版本和组件，尚未支持 TLS 1.3。对于这些组件，可以将 OpenShift 组件配置为使用 TLS 1.2。请注意，单个 TLS 连接需要在客户端和服务器端都兼容。如果只在服务器端组件中禁用旧的密码套件，可能会阻止旧的客户端与它进行连接。在生产环境中使用以下配置前，请首先进行全面测试。

TLS 1.2 Cipher Suites

一个单一密码套件定义了 Key Exchange (Kx) 方法, Key Exchange Authentication (Au) 方法（ 如 Certificate key 类型) , bulk Encryption (Enc) 方法和 Message Authentication (Mac) 方法限制为使用 TLS 1.2 密码套件是一个很好的起点，因为这个版本已修复了早期版本中已知的弱加密原语，如 CBC (存在安全漏洞 Lucky13/CVE-2013-0169) 和 DES/3DES (存在安全漏洞 Sweet32/CVE-2016-2183)。

但是，在 TLS 1.2 密码套件中包含了在 TLS 1.3 中不再支持的方法。例如 RSA for Key Exchange 和 non-AEAD methods for Message Authentication

TLS 1.2 Cipher Suites

ECDHE-ECDSA-AES256-GCM-SHA384  Kx=ECDH  Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384  Kx=ECDH    Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305  Kx=ECDH  Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305  Kx=ECDH    Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256  Kx=ECDH  Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256  Kx=ECDH    Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-SHA256  Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES128-SHA256  Kx=ECDH   Au=RSA  Enc=AES(128)  Mac=SHA256
AES256-GCM-SHA384      Kx=RSA   Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES128-GCM-SHA256      Kx=RSA   Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES256-SHA256          Kx=RSA   Au=RSA  Enc=AES(256)  Mac=SHA256
AES128-SHA256          Kx=RSA   Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES256-GCM-SHA384  Kx=DH    Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-CHACHA20-POLY1305  Kx=DH    Au=RSA  Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256  Kx=DH    Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES256-SHA256  Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES128-SHA256  Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256

（请注意，使用 AES CCM 进行批量加密的密码套件已从上面删除，RHEL7 中的 Go crypto/tls 或 OpenSSL 不支持它们）

用于密钥交换的 RSA 方法已从 TLS 1.3 中删除，因为它不提供 Forward Secrecy。因此，应避免选择使用 RSA 进行密钥交换的密码套件。

TLS 1.3 不再支持使用非 AEAD 算法用于消息完整性的密码套件，因此应避免使用。

TLS 1.2 支持的、没有使用上面提到的已弃用方法的密码套件是：

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES128-GCM-SHA256

但是，需要考虑以下情况：

  • 在 RHEL7 中，OpenSSL 不支持 CHACHA20/POLY1305 用于批量加密

  • Go crypto/tls不支持 DHE 用于密钥交换（如非 Elliptic Curve DH）

如果排除这些，所剩的密码套件为：

ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256

这个列表等同于 Intermediate Mozilla 列表（排除 TLS 1.3 和不支持的密码套件）。

以上密码套件使用 TLS 1.3 中提供的相同原语，因此可提供完美的转发保密，强大的批量加密并使用 AEAD 用于处于信息完整性。通过将选择使用的密码套件限制在上面的集合中，可以防止在 TLS 连接受已知安全漏洞（如 Sweet32,Lucky13）的影响。但是，TLS 1.3 还提供了其他几个安全增强（请参阅附录），使用上述 TLS 1.2 密码套件不应被视为具有与 TLS 1.3 等效的安全性。

以下密码套件在 TLS 1.3 中是新的，是协议规格下唯一支持的选项。

TLS 1.3 Cipher Suites

TLS_AES_256_GCM_SHA384         Kx=any   Au=any  Enc=AESGCM(256)          Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 Kx=any     Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256       Kx=any     Au=any  Enc=AESGCM(128)          Mac=AEAD
TLS_AES_128_CCM_SHA256       Kx=any     Au=any  Enc=AESCCM(128)          Mac=AEAD

TLS 1.3 中的新密码套件以不同的方式定义，且没有指定证书类型（如 RSA）或密钥交换机制（如 DHE 或 ECHDE），尽管这些算法仍然被支持[0][1]。

TLS 配置

请注意，在以下步骤中需要将密码套件的名称从 OpenSSL 名称转换为 IANA 名称（例如，将 ECDHE-RSA-AES256-GCM-SHA384 转换为 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384）

OpenShift 3.11

OpenShift 3.11 不支持在 Go 版本 1.12 中添加的 TLS 1.3，OpenShift 3.11 核心组件使用 Go 版本 1.10 构建。OpenShift 3.11 中使用的 HAProxy 路由没有使用 Go 编写，它使用由 RHEL7 提供的 OpenSSL 版本，不支持 TLS 1.3。

Master

使用所需的密码套件编辑 /etc/origin/master/master-config.yaml ：

 servingInfo:
    …
    minTLSVersion: VersionTLS12
    cipherSuites:  
    - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

然后重启 master 服务：

$ /usr/local/bin/master-restart api api && /usr/local/bin/master-restart controllers controllers

此处所做的 TLS 更改也会应用到 Etcd 实例。

https://access.redhat.com/solutions/3374601

Web Console

$ oc edit configmap webconsole-config -n  openshift-web-console
  ...
 servingInfo:
    …
    minTLSVersion: VersionTLS12
    cipherSuites:  
    - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

节点

Kubelet (端口 10248, 10250)

$ oc edit configmap node-config-infra -n  openshift-node
  ...
 servingInfo:
    …
    minTLSVersion: VersionTLS12
    cipherSuites:  
    - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Master、Infra 和 Compute 节点各自都有需要单独编辑的 ConfigMap。

路由

对于路由，需要使用 OpenSSL 密码套件名称。（可选）我们也可以重新添加 Go crypto/tls 软件包不支持的两个密码套件（路由中的 HAProxy 没有使用 Go 编写，使用 OpenSSL）。

OCP 3.11 中的路由与所有基于 RHEL7 的产品一样，使用的 OpenSSL 版本不支持 TLS 1.3。

$ oc edit deploymentconfig router -n default
...
    - name: ROUTER_CIPHERS
      value: ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256
    - name: SSL_MIN_VERSION
      value: TLSv1.2
...

以上配置仅适用于集群路由。还应检查单个服务是否与任何路由配置的更改兼容，因为后端服务器组件可能也需要进行类似的更改（取决于它们是边缘终止还是透传）。

https://docs.openshift.com/container-platform/3.11/architecture/networking/routes.html#ciphers

https://docs.openshift.com/container-platform/3.11/install_config/router/default_haproxy_router.html#bind-ciphers

请注意，路由 TLS 配置更改目前不会影响用于路由指标的端口 1936。

etcd

etcd （端口 2379、9977-9））将继承 Master 配置更改：

https://docs.openshift.com/container-platform/3.11/install_config/master_node_configuration.html#master-config-tls-cipher

OpenShift 4

从版本 4.2 起，OpenShift 4 已使用 Go 1.12 构建，因此在大部分组件中都支持 TLS 1.3。在 Openshift 4.6 之前，路由使用的来自 RHEL7 的 HAProxy 和 OpenSSL 尚不支持 TLS 1.3。在以后的版本中，路由基于 RHEL，并支持 TLS 1.3。

OCP 4 - Master

编写本文时，最新版本的 OpenShift 4 (4.7) 支持 TLS 1.3，API 服务器（端口 6443）被配置为使用 "Intermediate" TLS 安全配置集，它包括了一个精简的来自 TLS 1.3 和 1.2 的密码套件，其中没有任何已知的安全漏洞。因此不需要进一步配置 API 服务器。但是如果用户需要进一步配置它，请使用以下配置：

https://docs.openshift.com/container-platform/4.7/rest_api/config_apis/apiserver-config-openshift-io-v1.html

TLS 1.2:
    ECDHE-RSA-AES256-GCM-SHA384
    ECDHE-RSA-CHACHA20-POLY1305
    ECDHE-RSA-AES128-GCM-SHA256
TLS 1.3:
    TLS_AES_256_GCM_SHA384
    TLS_CHACHA20_POLY1305_SHA256
    TLS_AES_128_GCM_SHA256

一些其他内部服务，如 kube-controller （端口 10257）和 kube-scheduler（端口 10259）使用了一个稍微有所扩展的密码套件，但它们在 OpenShift Container Platform 版本 4.8.2 之前是无法进行配置的。版本 4.8.2 引入了一个变化，允许配置密码套件，且默认只启用已知的安全密码套件。

OCP 4 - Web 控制台

TLS 无法在 OpenShift Container Platform 4.7 及更早版本的 Web 控制台中配置。版本 4.5.13 引入了一个更改，它弃用了旧的存在安全漏洞的密码套件，并使用通用 OpenShift 默认的安全集。

OCP 4 - 节点

Kubelet (端口 10248, 10250)

$ oc label machineconfigpool worker custom-kubelet=tls-ciphers
$ oc label machineconfigpool master custom-kubelet=tls-ciphers
$ oc create -f kubeletconfig.yaml
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: tls-ciphers
spec:
  machineConfigPoolSelector:
    matchLabels:
      custom-kubelet: tls-ciphers
  kubeletConfig:
    tlsCipherSuites:
    - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
    - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

https://docs.openshift.com/container-platform/4.7/scalability_and_performance/recommended-host-practices.html#create-a-kubeletconfig-crd-to-edit-kubelet-parameters_

对于 kubelet，在 Kubernetes 1.19 和 OpenShift 4.6 之前，无法通过配置来声明 TLS 1.3 密码套件。但是，除了在配置中声明的 TLS 1.2 密码套件外，也会为 kubelet 启用 TLS 1.3 密码套件。

OCP 4 - 路由

在 OpenShift 4.6 之前，路由使用一组强化的 TLS 1.2 密码套件。因为 HAProxy 路由依赖于来自 RHEL7 的 OpenSSL，TLS 1.3 不被支持：

ECDHE-RSA-AES128-GCM-SHA256              
ECDHE-RSA-AES256-GCM-SHA384          
DHE-RSA-AES128-GCM-SHA256                
DHE-RSA-AES256-GCM-SHA384

但是，可以使用以下方法来进一步进行自定义（这里出于演示目的，我们删除了两个密码套件）：

$ oc edit ingresscontroller default -n openshift-ingress-operator
spec:
  tlsSecurityProfile:
    type: Custom
    custom:
    ciphers:
    - ECDHE-ECDSA-AES128-GCM-SHA256
    - ECDHE-RSA-AES128-GCM-SHA256
    minTLSVersion: VersionTLS12

在 OpenShift 4.6 及更高版本中，路由基于 RHEL8，支持 TLS 1.3。

https://docs.openshift.com/container-platform/4.6/networking/ingress-operator.html#nw-ingress-controller-tls-profiles_configuring-ingress

OCP 4 - Etcd

端口 9977-9, 2379, 2380

在 OpenShift Container Platform 4.6 和更早的版本中，对于 Etcd，TLS 是不可配置的。版本 4.6.16 引入了一个更改，它弃用了旧的存在安全漏洞的密码套件，并使用通用 OpenShift 默认的安全集。

OCP 4 - 机器配置服务器

端口 22623-4

在 OpenShift Container Platform 4.8.2 之前，对于 Machine Config Server，TLS 是不可配置的。版本 4.8.2 引入了一个更改，它默认只启用已知的安全密码套件。

OCP 4 - 节点导出器

端口 9100-9101

在 OpenShift Container Platform 4.6.1 之前，对于 Node Exporter，TLS 是不可配置的。版本 4.6.1 引入了一个更改，它默认只启用已知的安全密码套件。

OCP 4 - Kube RBAC Proxy

端口 9192

在 OpenShift Container Platform 4.8.2 之前，对于 Kube RBAC Proxy，TLS 是不可配置的。版本 4.8.2 引入了一个更改，它默认只启用已知的安全密码套件。

附录

其他 TLS 1.3 安全改进

  • TLS 1.3 删除了弱原语：如 RC4、SHA1、MD5。

    在 OpenShift 中已不再被支持

  • 删除 CBC 模式密码套件

    例如 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA ,TLS_RSA_WITH_AES_128_CBC_SHA, DES-CBC3-SHA

  • 在握手中没有使用 ChangeCipherSpec 信息：

    TLS 1.3 中不需要（为了实现与早期 TLS 版本兼容除外）。这些消息没有已知的安全问题，但之前会受 CVE-2014-0224 影响。

  • 没有压缩协商

  • Re-key 机制

    替换了会话重新协商，OpenShift 中默认禁用客户端会话重新协商

  • 删除 PKCS#1 v1.5 padding

    这只适用于 RSA 密钥交换，不适用已禁用了使用 RSA 密钥交换的密码套件。

  • 删除了一些 DHE 组

    不再支持自定义组，TLS 1.3 支持以下 curves：

    X25519, prime256v1, secp384r1 https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility

  • DSA 证书不再被支持

    在 OpenShift 中，默认已不再被支持

  • Anti-downgrade 功能

  • 在握手过程中加密扩展

  • 新改进的会话恢复功能

  • 新的 ECC curve：Curve 25519 和 Curve 448

其他参考信息

https://access.redhat.com/blogs/766093/posts/2975791

https://access.redhat.com/blogs/766093/posts/2978671

Comments