修复 K8s SSL/TLS 漏洞（CVE-2016-2183）指南

news2024/10/5 14:15:22

作者：老 Z，中电信数智科技有限公司山东分公司运维架构师，云原生爱好者，目前专注于云原生运维，云原生领域技术栈涉及 Kubernetes、KubeSphere、DevOps、OpenStack、Ansible 等。

前言

内容导图

测试服务器配置

主机名IPCPU内存系统盘数据盘用途
zdeops-master192.168.9.92440200Ansible 运维控制节点
ks-k8s-master-0192.168.9.9141640200+200KubeSphere/k8s-master/k8s-worker
ks-k8s-master-1192.168.9.9241640200+200KubeSphere/k8s-master/k8s-worker
ks-k8s-master-2192.168.9.9341640200+200KubeSphere/k8s-master/k8s-worker
storage-node-0192.168.9.952840200+200ElasticSearch/GlusterFS
storage-node-0192.168.9.962840200+200ElasticSearch/GlusterFS
storage-node-0192.168.9.972840200+200ElasticSearch/GlusterFS
harbor192.168.9.892840200Harbor
合计822843202800

测试环境涉及软件版本信息

  • 操作系统：CentOS-7.9-x86_64
  • Ansible：2.8.20
  • KubeSphere：3.3.0
  • Kubernetes：v1.24.1
  • GlusterFS：9.5.1
  • ElasticSearch：7.17.5
  • Harbor：2.5.1

简介

生产环境 KubeSphere 3.3.0 部署的 Kubernetes 集群在安全评估的时候发现安全漏洞，其中一项漏洞提示 SSL/TLS 协议信息泄露漏洞 (CVE-2016-2183)。

本文详细描述了漏洞产生原因、漏洞修复方案、漏洞修复的操作流程以及注意事项。

漏洞信息及修复方案

漏洞详细信息

漏洞报告中涉及漏洞 SSL/TLS 协议信息泄露漏洞 (CVE-2016-2183) 的具体信息如下：

kubesphere-ssl-tls-0

kubesphere-ssl-tls-1

漏洞分析

  1. 分析漏洞报告信息，我们发现漏洞涉及以下端口和服务：
端口号服务
2379/2380Etcd
6443kube-apiserver
10250kubelet
10257kube-controller
10259kube-scheduler
  1. 在漏洞节点 (任意 Master 节点) 查看、确认端口号对应的服务：
# ETCD
[root@ks-k8s-master-0 ~]# ss -ntlup | grep Etcd | grep -v "127.0.0.1"
tcp    LISTEN     0      128    192.168.9.91:2379                  *:*                   users:(("Etcd",pid=1341,fd=7))
tcp    LISTEN     0      128    192.168.9.91:2380                  *:*                   users:(("Etcd",pid=1341,fd=5))

# kube-apiserver
[root@ks-k8s-master-0 ~]# ss -ntlup | grep 6443
tcp    LISTEN     0      128    [::]:6443               [::]:*                   users:(("kube-apiserver",pid=1743,fd=7))

# kubelet
[root@ks-k8s-master-0 ~]# ss -ntlup | grep 10250
tcp    LISTEN     0      128    [::]:10250              [::]:*                   users:(("kubelet",pid=1430,fd=24))

# kube-controller
[root@ks-k8s-master-0 ~]# ss -ntlup | grep 10257
tcp    LISTEN     0      128    [::]:10257              [::]:*                   users:(("kube-controller",pid=19623,fd=7))

# kube-scheduler
[root@ks-k8s-master-0 ~]# ss -ntlup | grep 10259
tcp    LISTEN     0      128    [::]:10259              [::]:*                   users:(("kube-scheduler",pid=1727,fd=7))
  1. 漏洞原因：

相关服务配置文件里使用了 IDEA、DES 和 3DES 等算法。

  1. 利用测试工具验证漏洞：

可以使用 Nmap 或是 openssl 进行验证，本文重点介绍 Nmap 的验证方式。

注意：openssl 的方式输出太多且不好直观判断，有兴趣的可以参考命令 openssl s_client -connect 192.168.9.91:10257 -cipher "DES:3DES"。

在任意节点安装测试工具 Nmap ，并执行测试命令。

错误的姿势，仅用于说明选择 Nmap 版本很重要，实际操作中不要执行。

# 用 CentOS 默认源安装 nmap
yum install nmap

# 执行针对 2379 端口的 ssl-enum-ciphers 检测
nmap --script ssl-enum-ciphers -p 2379 192.168.9.91

# 结果输出如下
Starting Nmap 6.40 ( http://nmap.org ) at 2023-02-13 14:14 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00013s latency).
PORT     STATE SERVICE
2379/tcp open  unknown

Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds

注意： 分析输出的结果发现并没有任何警告信息。原因是 Nmap 版本过低，需要 7.x 以上才可以。

正确的姿势，实际执行的操作：

# 从 Nmap 官网，下载安装新版软件包
rpm -Uvh https://nmap.org/dist/nmap-7.93-1.x86_64.rpm

# 执行针对 2379 端口的 ssl-enum-ciphers 检测
# nmap -sV --script ssl-enum-ciphers -p 2379 192.168.9.91 (该命令输出更为详细也更加耗时，为节省篇幅使用下面简单输出的模式)
nmap --script ssl-enum-ciphers -p 2379 192.168.9.91

# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-13 17:28 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00013s latency).

PORT     STATE SERVICE
2379/tcp open  Etcd-client
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (ecdh_x25519) - C
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds

# 执行针对 2380 端口的 ssl-enum-ciphers 检测
nmap --script ssl-enum-ciphers -p 2380 192.168.9.91

# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-13 17:28 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00014s latency).

PORT     STATE SERVICE
2380/tcp open  Etcd-server
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (ecdh_x25519) - C
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: client
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 0.64 seconds

# 执行针对 6443 端口的 ssl-enum-ciphers 检测（10250/10257/10259 端口扫描结果相同）
nmap --script ssl-enum-ciphers -p 6443 192.168.9.91

# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-13 17:29 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00014s latency).

PORT     STATE SERVICE
6443/tcp open  sun-sr-https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (secp256r1) - C
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.3:
|     ciphers:
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|     cipher preference: server
|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds

注意： 扫描结果中重点关注 warnings，64-bit block cipher 3DES vulnerable to SWEET32 attack。

漏洞修复方案

漏洞扫描报告中提到的修复方案并不适用于 Etcd、Kubernetes 相关服务。

针对于 Etcd、Kubernetes 等服务有效的修复手段是修改服务配置文件，禁用 3DES 相关的加密配置。

Cipher Suites 配置参数的选择，可以参考 ETCD 官方文档或是 IBM 私有云文档，网上搜到的很多配置都是参考的 IBM 的文档，想省事的可以拿来即用。

对于配置参数的最终选择，我采用了最笨的方法，即把扫描结果列出的 Cipher 值拼接起来。由于不清楚影响范围，所以保守的采用了在原有配置基础上删除 3DES 相关的配置。

下面的内容整理了 Cipher Suites 配置参数的可参考配置。

  1. 原始扫描结果中的 Cipher Suites 配置：
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384
  1. 原始扫描结果去掉 3DES 的 Cipher Suites 配置：
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384

使用该方案时必须严格按照以下顺序配置，我在测试时发现顺序不一致会导致 Etcd 服务反复重启。

ETCD_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA

虽然 CIPHER 配置一样，但是在使用下面的顺序时，Etcd 服务反复重启，我排查了好久也没确定根因。也可能是我写的有问题，但是比对多次也没发现异常，只能暂时是认为是顺序造成的。

ETCD_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384

注意： 只有 Etcd 服务受到顺序的影响，kube 相关组件顺序不同也没发现异常。

  1. IBM 相关文档中的 Cipher Suites 配置：

网上搜到的参考文档使用率最高的配置。实际测试也确实好用，服务都能正常启动，没有发现 Etcd 不断重启的现象。如果没有特殊需求，可以采用该方案，毕竟选择越少出安全漏洞的几率也越小。

- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

漏洞修复

建议使用以下顺序修复漏洞：

  • Etcd
  • kube-apiserver
  • kube-controller
  • kube-scheduler
  • kubelet

上面的操作流程中，重点是将 Etcd 的修复重启放在最前面执行。因为 kube 等组件的运行依赖于 Etcd，我在验证时最后升级的 Etcd，当 Etcd 启动失败后（反复重启），其他服务由于无法连接 Etcd，造成服务异常停止。所以先确保 Etcd 运行正常再去修复其他组件。

本文所有操作仅演示了一个节点的操作方法，多节点存在漏洞时请按组件依次执行，先修复完成一个组件，确认无误后再去修复另一个组件。

以下操作是我实战验证过的经验，仅供参考，生产环境请一定要充分验证、测试后再执行！

修复 Etcd

  1. 编辑 Etcd 配置文件 /etc/Etcd.env：

KubeSpere 3.3.0 采用二进制的方式部署的 Etcd，相关配置文件包含 /etc/systemd/system/Etcd.service 和 /etc/Etcd.env，参数配置保存在 /etc/Etcd.env。

# 在文件最后增加配置(用 cat 命令自动配置)
cat >> /etc/Etcd.env << "EOF"

# TLS CIPHER SUITES settings
ETCD_CIPHER_SUITES=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
EOF
  1. 重启 Etcd 服务：
# 重启服务
systemctl restart Etcd

# 验证服务已启动
ss -ntlup | grep Etcd

# 正确的结果如下
tcp    LISTEN     129    128    192.168.9.91:2379                  *:*                   users:(("Etcd",pid=40160,fd=7))
tcp    LISTEN     0      128    127.0.0.1:2379                  *:*                   users:(("Etcd",pid=40160,fd=6))
tcp    LISTEN     0      128    192.168.9.91:2380                  *:*                   users:(("Etcd",pid=40160,fd=5))

# 持续观测 确保服务没有反复重启
watch -n 1 -d 'ss -ntlup | grep Etcd'

注意： 如果是多节点模式，一定要所有节点都修改完配置文件，然后，所有节点同时重启 Etcd 服务。重启过程中会造成 Etcd 服务中断，生产环境谨慎操作。

  1. 验证漏洞是否修复：
# 执行扫描命令
nmap --script ssl-enum-ciphers -p 2379 192.168.9.91

# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-14 17:48 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00015s latency).

PORT     STATE SERVICE
2379/tcp open  Etcd-client
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: client
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 0.64 seconds

# 为了节省篇幅，2380 端口扫描完整输出结果略,实际结果与 2379 端口一致

# 可以执行过滤输出的扫描命令，如果以下命令返回值为空，说明漏洞修复
nmap --script ssl-enum-ciphers -p 2380 192.168.9.91 | grep SWEET32

修复 kube-apiserver

  1. 编辑 kube-apiserver 配置文件 /etc/kubernetes/manifests/kube-apiserver.yaml：
# 新增配置(在原文件 47 行后面增加一行)
- --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA

# 新增后的效果如下（不截图了，增加了行号显示用来区分）
46     - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
47     - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
48     - --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_        256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
  1. 重启 kube-apiserver：

不需要手动重启，由于是静态 Pod， Kubernetes 会自动重启。

  1. 验证漏洞：
# 执行扫描命令
nmap --script ssl-enum-ciphers -p 6443 192.168.9.91

# 输出结果如下
Starting Nmap 7.93 ( https://nmap.org ) at 2023-02-14 09:22 CST
Nmap scan report for ks-k8s-master-0 (192.168.9.91)
Host is up (0.00015s latency).

PORT     STATE SERVICE
6443/tcp open  sun-sr-https
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.3:
|     ciphers:
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|     cipher preference: server
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 0.68 seconds

注意：对比之前的漏洞告警信息，扫描结果中已经不存在 64-bit block cipher 3DES vulnerable to SWEET32 attack，说明修复成功。

修复 kube-controller

  1. 编辑 kube-controller 配置文件 /etc/kubernetes/manifests/kube-controller-manager.yaml：
# 新增配置(在原文件 33 行后面增加一行)
- --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA

# 新增后的效果如下（不截图了，增加了行号显示用来区分）
33     - --use-service-account-credentials=true
34     - --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_        256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
  1. 重启 kube-controller：

不需要手动重启，由于是静态 Pod， Kubernetes 会自动重启。

  1. 验证漏洞：
# 执行完整扫描命令
nmap --script ssl-enum-ciphers -p 10257 192.168.9.91

# 为了节省篇幅，完整输出结果略,实际结果与 kube-apiserver 的一致

# 可以执行过滤输出的扫描命令，如果以下命令返回值为空，说明漏洞修复
nmap --script ssl-enum-ciphers -p 10257 192.168.9.91 | grep SWEET32

注意：对比之前的漏洞告警信息，扫描结果中已经不存在 64-bit block cipher 3DES vulnerable to SWEET32 attack，说明修复成功。

修复 kube-scheduler

  1. 编辑 kube-scheduler 配置文件 /etc/kubernetes/manifests/kube-scheduler.yaml：
# 新增配置(在原文件 19 行后面增加一行)
- --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA

# 新增后的效果如下（不截图了，增加了行号显示用来区分）
19     - --leader-elect=true
20     - --tls-cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_  256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
  1. 重启 kube-scheduler：

不需要手动重启，由于是静态 Pod， Kubernetes 会自动重启。

  1. 验证漏洞：
# 执行完整扫描命令
nmap --script ssl-enum-ciphers -p 10259 192.168.9.91

# 为了节省篇幅，完整输出结果略,实际结果与 kube-apiserver 的一致

# 可以执行过滤输出的扫描命令，如果以下命令返回值为空，说明漏洞修复
nmap --script ssl-enum-ciphers -p 10259 192.168.9.91 | grep SWEET32

注意：对比之前的漏洞告警信息，扫描结果中已经不存在 64-bit block cipher 3DES vulnerable to SWEET32 attack，说明修复成功。

修复 kubelet

  1. 编辑 kubelet 配置文件 /var/lib/kubelet/config.yaml：
# 在配置文件最后添加
tlsCipherSuites: [TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_  256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA]

提示： 更多的 cipher suites 配置，请参考 Kubernetes 官方文档。

  1. 重启 kubelet：
systemctl restart kubelet

重启有风险，操作需谨慎！

  1. 验证漏洞：
# 执行完整扫描命令
nmap --script ssl-enum-ciphers -p 10250 192.168.9.91

# 为了节省篇幅，完整输出结果略,实际结果与 kube-apiserver 的一致

# 可以执行过滤输出的扫描命令，如果以下命令返回值为空，说明漏洞修复
nmap --script ssl-enum-ciphers -p 10250 192.168.9.91 | grep SWEET32

注意： 对比之前的漏洞告警信息，扫描结果中已经不存在 64-bit block cipher 3DES vulnerable to SWEET32 attack，说明修复成功。

常见问题

Etcd 启动失败

报错信息：

Feb 13 16:17:41 ks-k8s-master-0 Etcd: Etcd Version: 3.4.13
Feb 13 16:17:41 ks-k8s-master-0 Etcd: Git SHA: ae9734ed2
Feb 13 16:17:41 ks-k8s-master-0 Etcd: Go Version: go1.12.17
Feb 13 16:17:41 ks-k8s-master-0 Etcd: Go OS/Arch: linux/amd64
Feb 13 16:17:41 ks-k8s-master-0 Etcd: setting maximum number of CPUs to 4, total number of available CPUs is 4
Feb 13 16:17:41 ks-k8s-master-0 Etcd: the server is already initialized as member before, starting as Etcd member...
Feb 13 16:17:41 ks-k8s-master-0 Etcd: unexpected TLS cipher suite "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"
Feb 13 16:17:42 ks-k8s-master-0 systemd: Etcd.service: main process exited, code=exited, status=1/FAILURE
Feb 13 16:17:42 ks-k8s-master-0 systemd: Failed to start Etcd.
Feb 13 16:17:42 ks-k8s-master-0 systemd: Unit Etcd.service entered failed state.
Feb 13 16:17:42 ks-k8s-master-0 systemd: Etcd.service failed.

解决方案：

删除配置文件中的 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 字段，至于原因没有深入研究。

Etcd 服务不断重启

报错信息 (省略掉了一部分)：

修改配置文件后，重新启动 Etcd，启动的时候命令执行没有报错。但是，启动后查看 status 有异常，且 /var/log/messages 中有如下信息

Feb 13 16:25:55 ks-k8s-master-0 systemd: Etcd.service holdoff time over, scheduling restart.
Feb 13 16:25:55 ks-k8s-master-0 systemd: Stopped Etcd.
Feb 13 16:25:55 ks-k8s-master-0 systemd: Starting Etcd...
Feb 13 16:25:55 ks-k8s-master-0 Etcd: recognized and used environment variable ETCD_ADVERTISE_CLIENT_URLS=https://192.168.9.91:2379
Feb 13 16:25:55 ks-k8s-master-0 Etcd: [WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag instead
Feb 13 16:25:55 ks-k8s-master-0 Etcd: [WARNING] Deprecated '--logger=capnslog' flag is set; use '--logger=zap' flag instead
Feb 13 16:25:55 ks-k8s-master-0 Etcd: recognized and used environment variable ETCD_AUTO_COMPACTION_RETENTION=8
.....（省略）

Feb 13 16:25:58 ks-k8s-master-0 systemd: Started Etcd.
Feb 13 16:25:58 ks-k8s-master-0 Etcd: serving client requests on 192.168.9.91:2379
Feb 13 16:25:58 ks-k8s-master-0 Etcd: serving client requests on 127.0.0.1:2379
Feb 13 16:25:58 ks-k8s-master-0 Etcd: accept tcp 127.0.0.1:2379: use of closed network connection
Feb 13 16:25:58 ks-k8s-master-0 systemd: Etcd.service: main process exited, code=exited, status=1/FAILURE
Feb 13 16:25:58 ks-k8s-master-0 systemd: Unit Etcd.service entered failed state.
Feb 13 16:25:58 ks-k8s-master-0 systemd: Etcd.service failed.

解决方案：

在实际测试中遇到了两种场景都产生了类似上面的报错信息：

第一种，在多节点 Etcd 环境中，需要先修改所有节点的 Etcd 配置文件，然后，同时重启所有节点的 Etcd 服务。

第二种，Etc Cipher 参数顺序问题，不断尝试确认了最终顺序后（具体配置参考正文），反复重启的问题没有再现。

本文由博客一文多发平台 OpenWrite 发布！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/360851.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

模电中的负反馈

模电中的负反馈

文章目录一、反馈是什么&#xff1f;二、负反馈对于放大性能的影响1.负反馈的作用三、正反馈总结– 一、反馈是什么&#xff1f; 反馈的定义&#xff1a;凡是将放大电路输出端信号&#xff08;电压或电流&#xff09;的一部分或者全部引回到输入端&#xff0c;与输入信号叠加…
阅读更多...
【C语言】宏

【C语言】宏

&#x1f680;write in front&#x1f680; &#x1f4dc;所属专栏&#xff1a;> c语言学习 &#x1f6f0;️博客主页&#xff1a;睿睿的博客主页 &#x1f6f0;️代码仓库&#xff1a;&#x1f389;VS2022_C语言仓库 &#x1f3a1;您的点赞、关注、收藏、评论&#xff0c;是…
阅读更多...
打造Ai作图studio需要哪些工具

打造Ai作图studio需要哪些工具

这篇文章依然是比较轻松的方式跟大家介绍Ai生成会使用到的一些工具&#xff0c;希望这些工具可以帮助到你更好的更稳定的快捷的生成高质量图片。说来轻松其实也不算轻松&#xff0c;虽然我已经按照生成的链路对工具做了规整。但是里面涉及到的工具其实确实不算少&#xff0c;并…
阅读更多...
2023-02-20 Qt 5.13.1 + OpenCV 4.5.4环境编译

2023-02-20 Qt 5.13.1 + OpenCV 4.5.4环境编译

引言 OpenCV图像处理在Qt中编译记录。 之前一直是在Python中使用OpenCV&#xff0c;Python中使用某些模块使用pip工具很容易将对应的模块安装在系统中。根据项目需求项目都要转移在国产化中使用&#xff0c;为了适应国产化需求&#xff0c;将代码转移到Qt开发环境中&#xff0c…
阅读更多...
django项目实战四（django+bootstrap实现增删改查）进阶时间控件

django项目实战四（django+bootstrap实现增删改查）进阶时间控件

接上一篇《django项目实战三&#xff08;djangobootstrap实现增删改查&#xff09;进阶分页》 知识点&#xff1a; 使用bootstrap-datepicker实现时间控件 一、优化layout.html模版 主要新增2个块 {% block css %}{% endblock %}{% block js %}{% endblock %} {% load static…
阅读更多...
nginx.conf配置方法详细介绍

nginx.conf配置方法详细介绍

从前面的内容学习中&#xff0c;我们知道Nginx的核心配置文件默认是放在/usr/local/nginx/conf/nginx.conf&#xff0c;这一节&#xff0c;我们就来学习下nginx.conf的内容和基本配置方法。读取Nginx自带的Nginx配置文件&#xff0c;我们将其中的注释部分【学习一个技术点就是在…
阅读更多...
第20讲：Python列表、元组、字符串使用自定义排序规则

第20讲：Python列表、元组、字符串使用自定义排序规则

文章目录1.自定义排序方法2.常用作自定义排序的函数、方法3.列表、元组、字符串自定义排序方法3.1.当列表、元组中元素为字符串的排序规则3.2.三者采用str.lower方法实现自定义排序3.2.三者采用len函数实现自定义排序1.自定义排序方法 列表、元组、字符串都可以进行排序&#…
阅读更多...
友元的学习

友元的学习

&#x1f601;友元的简介类的主要特点之一是数据隐藏&#xff0c;即类的私有成员无法在类的外部作用域之外访问&#xff0c;但是&#xff0c;有时候需要在类的外部访问类的私有成员&#xff0c;这个时候就需要使用友元函数。友元函数是一种特权函数&#xff0c;c允许这哥特权函…
阅读更多...
分享在线预约系统制作步骤_在线预约链接怎么做

分享在线预约系统制作步骤_在线预约链接怎么做

在微信小程序上进行在线预约&#xff0c;不管是商家还是顾客&#xff0c;都可以自由选择时间&#xff0c;顾客还可以通过预约小程序&#xff0c;了解到所选服务的详情和功能特色&#xff0c;不必等到去店内听介绍&#xff0c;顾客能节省等候时间&#xff0c;商家能解放招待人力…
阅读更多...
解决：Vmware Workstation 和 Vmware ESXI 创建虚拟机Ubuntu20.04时界面显示不全，无法点击Continue进行下一步

解决：Vmware Workstation 和 Vmware ESXI 创建虚拟机Ubuntu20.04时界面显示不全，无法点击Continue进行下一步

目录 Vmware Workstation Vmware ESXI Vmware Workstation 1.如下图&#xff0c;到了这一步可以按 CTRL ALT T 调出命令终端 2. 终端输入 xrandr --size 1280x800 此命令是调整屏幕大小 3.此时已经显示屏幕完整信息 Vmware ESXI 安装workstation时那种调整界面大小的方…
阅读更多...
每日学术速递2.21

每日学术速递2.21

CV - 计算机视觉 | ML - 机器学习 | RL - 强化学习 | NLP 自然语言处理 Subjects: cs.CV 1.T2I-Adapter: Learning Adapters to Dig out More Controllable Ability for Text-to-Image Diffusion Models 标题&#xff1a;T2I-Adapter&#xff1a;学习Adapter&#xff0c;为…
阅读更多...
2022年网络安全政策态势分析与2023年立法趋势

2022年网络安全政策态势分析与2023年立法趋势

近日&#xff0c;公安部第三研究所网络安全法律研究中心与 360 集团法务中心联合共同发布了《全球网络安全政策法律发展年度报告&#xff08;2022&#xff09;》。《报告》概览2022年全球网络安全形势与政策法律态势&#xff0c;并对2023年及后续短期内网络安全政策、立法趋势进…
阅读更多...
【微信小程序】原生微信小程序ts模板下引入vant weapp

【微信小程序】原生微信小程序ts模板下引入vant weapp

之前一直是在普通项目下使用 vant weapp&#xff0c;这不最近学了ts&#xff0c;使用微信开发工具的tsless初始化项目&#xff0c;再引入 vant 时踩了好久坑&#xff0c;特来记录一下 前言 本文章适合微信开发工具的ts项目&#xff0c;指的是项目目录结构如下图 总结 从上图…
阅读更多...
Leetcode.1401 圆和矩形是否有重叠

Leetcode.1401 圆和矩形是否有重叠

题目链接 Leetcode.1401 圆和矩形是否有重叠 Rating &#xff1a; 1709 题目描述 给你一个以 (radius, xCenter, yCenter)表示的圆和一个与坐标轴平行的矩形 (x1, y1, x2, y2)&#xff0c;其中 (x1, y1)是矩形左下角的坐标&#xff0c;而 (x2, y2)是右上角的坐标。 如果圆和矩…
阅读更多...
【重点掌握】Java基础之Javaweb核心技术详解

【重点掌握】Java基础之Javaweb核心技术详解

都说一入Java深似海&#xff0c;从此代码是爱人&#xff0c;但是学习的过程却从来都不轻松。当下&#xff0c;越来越多的互联网企业&#xff0c;招聘Java工程师时&#xff0c;明确写道需熟练掌握JavaWeb技术。作为衔接前后端的重要一环&#xff0c;JavaWeb技术已成为程序员向大…
阅读更多...
Linux线程调度实验

Linux线程调度实验

Linux线程调度实验 1.获取线程属性 #include <stdio.h> #include <sys/types.h> #include <unistd.h> #include <pthread.h> #include <time.h> #include <stdlib.h> #include <errno.h> #define _GNU_SOURCE#define handle_error…
阅读更多...
Power Apps 中判断用户的SharePoint Online Group权限

Power Apps 中判断用户的SharePoint Online Group权限

前言 最近&#xff0c;碰到一个棘手的问题&#xff0c;就是用户有个需求&#xff0c;就是想在Power Apps中判断一个用户是不是在某些AD安全组中。 通常&#xff0c;这样的情况&#xff0c;都需要去AAD中进行判断&#xff0c;判断这个人在不在某些组中&#xff0c;有Graph API可…
阅读更多...
双因素方差分析全流程

双因素方差分析全流程

上篇文章讲述了“单因素方差分析全流程总结”&#xff0c;单因素方差分析只是考虑了一个自变量&#xff08;定类&#xff09;与一个因变量&#xff08;定量&#xff09;之间的关系&#xff0c;但是在实际问题研究中可能研究两个或者几个因素与因变量之间的关系&#xff0c;例如…
阅读更多...
监管持续，医疗卫生机构如何守好“涉疫”数据安全？

监管持续，医疗卫生机构如何守好“涉疫”数据安全？

肆虐三年的新冠疫情&#xff0c;影响着全球经济发展、社会正常运行&#xff0c;也成为网络攻击、勒索软件攻击快速增长的温床&#xff0c;“滋生”了一系列网络、数据安全问题&#xff0c;受到各界关注。最近&#xff0c;上线运行三年的 “粤康码”发布公告、官宣部分服务下线&…
阅读更多...
C++——map和set的应用总结

C++——map和set的应用总结

目录1. 关联式容器2. 键值对3. 树形结构的关联式容器3.1 set3.1.1 set的介绍3.1.2 set的使用3.2 multiset3.2.1 multiset的介绍3.2.2 multiset的使用3.3 map3.3.1 map的介绍3.3.2 map的使用operator[]3.4 multimap3.4.1 multimap的介绍3.4.2 multimap的使用3.5 map和set在OJ中的…
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023