文档
- 1: 简介
- 2: 准备
- 3: 正常安装
- 4: 脚本一键安装
- 5: Kubernetes
- 5.1: 修复的漏洞
- 5.1.1: CVE-2021-25741
- 5.1.2: CVE-2021-3121
- 5.1.3: CVE-2020-8559
- 5.1.4: CVE-2020-8558
- 5.1.5: CVE-2020-8552
- 5.1.6: CVE-2019-1002101
- 5.1.7: CVE-2019-11251
- 5.1.8: CVE-2019-11248
- 5.1.9: CVE-2019-11247
- 5.1.10: CVE-2019-11246
- 5.1.11: CVE-2019-11245
- 5.1.12: CVE-2019-11249
- 5.1.13: nokmem
- 5.2: 版本日志
- 5.2.1: v1.28
- 5.2.1.1: v1.28.15-lts.0
- 5.2.2: v1.27
- 5.2.2.1: v1.27.16-lts.0
- 5.2.3: v1.26
- 5.2.3.1: v1.26.15-lts.0
- 5.2.4: v1.25
- 5.2.4.1: v1.25.16-lts.0
- 5.2.5: v1.24
- 5.2.5.1: v1.24.17-lts.0
- 5.2.6: v1.23
- 5.2.6.1: v1.23.17-lts.0
- 5.2.6.2: v1.23.4-lts.1
- 5.2.7: v1.22
- 5.2.7.1: v1.22.17-lts.0
- 5.2.7.2: v1.22.8-lts.1
- 5.2.8: v1.21
- 5.2.8.1: v1.21.11-lts.1
- 5.2.9: v1.20
- 5.2.9.1: v1.20.15-lts.1
- 5.2.10: v1.19
- 5.2.10.1: v1.19.16-lts.3
- 5.2.11: v1.18
- 5.2.11.1: v1.18.20-lts.1
- 5.2.11.2: v1.18.20-lts.2
- 5.2.12: v1.17
- 5.2.12.1: v1.17.17-lts.1
- 5.2.13: v1.16
- 5.2.13.1: v1.16.15-lts.1
- 5.2.14: v1.15
- 5.2.14.1: v1.15.12-lts.1
- 5.2.15: v1.14
- 5.2.15.1: v1.14.10-lts.1
- 5.2.16: v1.13
- 5.2.16.1: v1.13.12-lts.1
- 5.2.17: v1.12
- 5.2.17.1: v1.12.10-lts.1
- 5.2.18: v1.11
- 5.2.18.1: v1.11.10-lts.1
- 5.2.19: v1.10
- 5.2.19.1: v1.10.13-lts.1
- 6: Containerd
- 6.1: 修复的漏洞
- 6.1.1: CVE-2021-41103
- 6.2: 版本日志
- 6.2.1: v1.3
- 6.2.1.1: v1.3.10-lts.1
- 7: 添加 CVE 补丁到 klts
- 8: 开发指南
1 - 简介
KLTS 全称为 Kubernetes Long Term Support，主要使命是为 Kubernetes 早期版本提供长期免费的维护支持。
之所以需要维护早期版本，是因为在实际生产环境中，最新版本不一定是最好的，也不是最稳定的。正常而言，Kubernetes 社区版本的维护周期只有一年左右，请参阅 Kubernetes 版本发行周期。在社区停止维护后，KLTS 在接下来的三年内提供免费维护服务。
在实际生产中，为什么大多数企业选择采用早期的 Kubernetes 版本管控集群呢？
-
首先，升级频率高会带来变更风险，每次升级必须进行充分验证。特别是金融行业的平台层变更周期通常比较长，因为一旦升级后的新版本存在 bug，就需要被迫回滚或快速响应升级至更新的版本，这样会造成不必要的成本支出。
-
其次，Kubernetes 升级后部分功能的替代方案还没有完全生产就绪，在生产环境中常会出现不兼容的状况。
-
最后，Kubernetes 社区仅支持小版本 +1 升级，不支持跨版本升级，因为跨版本升级经常会出现一些不可控的因素，造成更大的生产问题。
所以大多数企业的选择是沿用早期版本，不会贸然升级。但 Kubernetes 社区只维护最新的 3 到 4 个版本，如何才能保证这些早期版本免受社区不定时发现的 CVE 漏洞和 bug 的袭扰呢？这就是 KLTS 的价值所在！我们对早期版本提供长达 3 年的免费维护支持，积极修复早期版本的 CVE 安全漏洞和重大 bug。
KLTS 维护周期
Kubernetes 版本号表示为 x.y.z，其中 x 是大版本号，y 是小版本号，z 是补丁版本，KLTS 提供的补丁版本号通常以 lts1、lts2 … ltsn 表示。为了方便表述，本节用前两位 x.y 描述 Kubernetes 版本号。
假设社区发布的最新 Kubernetes 版本为 x.y，根据社区版本维护声明，社区仅维护最近的三个版本，而 KLTS 目前维护从 1.10 起的近十个早期版本，如下图所示。
当 Kubernetes 社区发现可能影响生产的 CVE 新漏洞或 bug，受到影响的可能不止是社区正在维护的版本，还有之前已经停止维护、但企业仍在使用、且不能贸然升级的版本，KLTS 团队维护的正是这些社区放弃维护的版本。目前 KLTS 的版本维护周期如下：
从上图可看出，Kubernetes 社区对某个版本的维护周期通常在一年左右，而 KLTS 可以在接下来的三年内提供长期维护，直至代码无法兼容，才会将相应版本淘汰。
KLTS 修复范围
有些高优先级的 CVE 或严重 Bug 存在于生产环境中会造成较大的安全隐患。CVE 安全问题是集群的生命线，KLTS 会优先修复中高级别的 CVE，其次会修复重大 Bug，确保生产环境稳定运行。
以 2021 年 1 月发现的 CVE-2021-3121 安全漏洞为例，CVSS 危急分数高达 7.5。但截止 2021 年 9 月 Kubernetes 社区：
- 仅修复了 4 个版本：1.18、1.19、1.20、1.21
- 宣称“所有早期版本均有这个安全漏洞，建议用户立即停止使用早期版本”
- 拒绝修复早期版本漏洞的要求
KLTS 针对这一现状，默默修复了深受 CVE-2021-3121 安全漏洞影响的 8 个早期版本：
- v1.17.17
- v1.16.15
- v1.15.12
- v1.14.10
- v1.13.12
- v1.12.10
- v1.11.10
- v1.10.13
如果您觉得 KLTS 团队的付出有价值，让您值得信赖，欢迎任何开发者加入 KLTS 社区交流并做出贡献。
欢迎携手培育硕果
辛勤的耕耘，最终收获的是美丽花朵和累累硕果。经过开发者精心的维护支持，KLTS 为这些早期版本带来以下成果：
-
三年维护期：Kubernetes 社区对每个版本提供一年左右的维护，而 KLTS 接下来会为该版本提供长达三年的持续维护。
-
安全稳定：小版本升级更安全，兼容性高。渐进式升级稳定性更好。譬如最新版本的新功能也许很有吸引力，但是不一定能达到生产可用的标准，需要较长时间的积累。
-
易于安装：结合国内镜像加速，原生支持 Kubeadm，支持 CentOS、Ubuntu、openSUSE，还提供了一键安装脚本。
-
公开透明：在 GitHub 托管的开源项目，全流程公开。
-
全链路规划：后续会添加 Containerd 及其他组件的长期维护。
在此也向广大的开发者，再次发出邀请，如果您觉得 KLTS 团队的付出有价值，让您值得信赖，欢迎任何开发者加入 KLTS 社区交流并贡献，期待您的任何意见、建议或解决方案。
- 加入 KLTS 社区
- 加入 KLTS Slack 聊天频道
Kubernetes 版本发行周期
Kubernetes 社区最近十多个版本的发布时间统计如下：
| K8s 版本 | 初次发布日期 | EOL 日期 |
|---|---|---|
| 1.10 | 2018-03-27 | 2019-02-13 |
| 1.11 | 2018-07-28 | 2019-05-01 |
| 1.12 | 2018-09-28 | 2019-07-08 |
| 1.13 | 2018-12-04 | 2019-10-15 |
| 1.14 | 2019-03-25 | 2019-12-11 |
| 1.15 | 2019-07-20 | 2020-05-06 |
| 1.16 | 2019-09-18 | 2020-09-02 |
| 1.17 | 2019-12-08 | 2021-01-13 |
| 1.18 | 2020-03-25 | 2021-06-18 |
| 1.19 | 2020-08-26 | 2021-10-28 |
| 1.20 | 2020-12-08 | 2022-02-28 |
| 1.21 | 2021-04-08 | 2022-06-28 |
| 1.22 | 2021-08-04 | 2022-10-28 |
初次发布：指的是 Kubernetes 初次发布的 0 号版本，即 1.10.0、1.11.0 … 1.22.0 等。
EOL 全称为 End Of Life，即官方社区结束维护，通常发生在初次发布大约 1 年后，这也是官方社区发布的最后一个 bug fix 版本。
2 - 准备
本页介绍安装 Kubernetes 之前需要做好的一些准备工作，例如先要安装 kubeadm 工具箱。有关在安装此工具箱后如何用其创建集群，请参阅正常安装。
准备工作
- 准备一台兼容的 Linux 主机。Kubernetes 项目为基于 Debian 和 Red Hat 的 Linux 发行版以及一些不提供包管理器的发行版提供通用的指令。
- 每台主机至少 2 GB 或更多的内存（如果内存太少将影响应用的运行）
- CPU 2 核或更多
- 集群中所有主机的网络连通（公网和内网）
- 单个节点上不能有重复的主机名、MAC 地址或 product_uuid，请参阅确保每个节点上 MAC 地址和 product_uuid 的唯一性。
- 开启主机上的某些端口，请参阅检查所需端口。
- 禁用交换分区。为了保证 kubelet 正常工作，您必须禁用交换分区。
确保每个节点上 MAC 地址和 product_uuid 的唯一性
- 使用命令
ip link或ifconfig -a来获取网络接口的 MAC 地址 - 使用
sudo cat /sys/class/dmi/id/product_uuid命令来校验 product_uuid
一般来讲，硬件设备拥有唯一的地址，但是有些虚拟机的地址可能会重复。 Kubernetes 使用 MAC 地址和 product_uuid 来确定集群中的唯一节点。 如果这些值在每个节点上不唯一，可能会导致安装失败。
检查网络适配器
如果您有一个以上的网络适配器，同时您的 Kubernetes 组件通过默认路由不可达，我们建议您预先添加 IP 路由规则，这样 Kubernetes 集群就可以通过对应的适配器完成连接。
允许 iptables 检查桥接流量
确保 br_netfilter 模块被加载。这一操作可以通过运行 lsmod | grep br_netfilter
来完成。若要显式加载该模块，可执行命令 sudo modprobe br_netfilter。
为了让您的 Linux 节点上的 iptables 能够正确地查看桥接流量，您需要确保在
sysctl 配置中将 net.bridge.bridge-nf-call-iptables 设置为 1。例如：
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
br_netfilter
EOF
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
sudo sysctl --system
更多细节请查阅网络插件需求页面。
检查所需端口
控制平面节点
| 协议 | 方向 | 端口范围 | 作用 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 6443 | Kubernetes API 服务器 | 所有组件 |
| TCP | 入站 | 2379-2380 | etcd 服务器客户端 API | kube-apiserver、etcd |
| TCP | 入站 | 10250 | Kubelet API | kubelet 自身、控制平面组件 |
| TCP | 入站 | 10251 | kube-scheduler | kube-scheduler 自身 |
| TCP | 入站 | 10252 | kube-controller-manager | kube-controller-manager 自身 |
工作节点
| 协议 | 方向 | 端口范围 | 作用 | 使用者 |
|---|---|---|---|---|
| TCP | 入站 | 10250 | Kubelet API | kubelet 自身、控制平面组件 |
| TCP | 入站 | 30000-32767 | NodePort 服务 | 所有组件 |
以上是 NodePort 服务的默认端口范围。
使用 * 标记的任意端口号都可以被覆盖，所以您需要保证定制的端口是开放的。
虽然控制平面节点已经包含了 etcd 的端口，您也可以使用自定义的外部 etcd 集群，或指定自定义端口。
您使用的 Pod 网络插件 (见下) 也可能需要某些特定端口开启。由于各个 Pod 网络插件都有所不同，请参阅相应文档中的端口要求。
设置节点名字
命令的语法格式如下：
hostnamectl set-hostname your-new-host-name
echo "127.0.0.1 $(hostname)" >> /etc/hosts
echo "::1 $(hostname)" >> /etc/hosts
关闭 Swap
执行以下命令关闭 Swap：
swapoff -a
如果需要永久关闭，请编辑 /etc/fstab 文件，将 swap 的挂载路径改为注释。
关闭 Selinux
执行以下命令关闭 Selinux：
setenforce 0
如果需要永久关闭，请编辑 /etc/sysconfig/selinux 将 SELINUX=enforcing 替换为 SELINUX=disabled。
安装 runtime
为了在 Pod 中运行容器，Kubernetes 使用容器运行时（Container Runtime）。
默认情况下，Kubernetes 使用容器运行时接口（Container Runtime Interface，CRI）来与您所选择的容器运行时交互。
如果您不指定运行时，则 kubeadm 会自动尝试检测系统上已经安装的运行时，方法是扫描一组众所周知的 Unix 域套接字。
下面的表格列举了一些容器运行时及其对应的套接字路径：
| 运行时 | 域套接字 |
|---|---|
| Docker | /var/run/dockershim.sock |
| Containerd | /run/containerd/containerd.sock |
| CRI-O | /var/run/crio/crio.sock |
如果同时检测到 Docker 和 Containerd，则优先选择 Docker。 这是必然的，即使您仅安装了 Docker，因为 Docker 18.09 附带了 Containerd，所以两者都是可以检测到的。 如果检测到其他两个或多个运行时，则 kubeadm 输出错误信息并退出。
kubelet 通过内置的 dockershim CRI 实现与 Docker 集成。
默认情况下， kubeadm 使用 docker 作为容器运行时。kubelet 通过内置的 dockershim CRI 实现与 Docker 集成。
执行以下命令安装基于 Red Hat 发行版的 Docker：
yum install docker
执行以下命令安装基于 Debian 发行版的 Docker：
apt-get install docker.io
Containerd 官方默认只提供 amd64 架构的下载包，如果您采用的是其他基础架构，
可以从 Docker 官方仓库安装 containerd.io 软件包。在安装 Docker 引擎中
找到为各自的 Linux 发行版设置 Docker 存储库和安装 containerd.io 软件包的有关说明。
也可以使用以下源代码构建。
VERSION=1.5.4
wget -c https://github.com/containerd/containerd/releases/download/v${VERSION}/containerd-${VERSION}-linux-amd64.tar.gz
tar xvf containerd-${VERSION}-linux-amd64.tar.gz -C /usr/local/
mkdir /etc/containerd/ && containerd config default > /etc/containerd/config.toml
wget -c -O /etc/systemd/system/containerd.service https://raw.githubusercontent.com/containerd/containerd/main/containerd.service
systemctl start containerd && systemctl enable containerd
参阅容器运行时以了解更多信息。
3 - 正常安装
KLTS 提供了基于 deb 和 rpm 软件源的安装方式，您可以选择适合的安装方式。
安装前请确认已经完成了准备工作。
设置 KLTS 软件源
执行以下代码设置下载 KLTS 的软件源：
VERSION=1.18.20-lts.2
cat << EOF > /etc/yum.repos.d/klts.repo
[klts]
name=klts
baseurl=https://raw.githubusercontent.com/klts-io/kubernetes-lts/rpm-v${VERSION}/\$basearch/
enabled=1
gpgcheck=0
[klts-other]
name=klts-others
baseurl=https://raw.githubusercontent.com/klts-io/others/rpm/\$basearch/
enabled=1
gpgcheck=0
EOF
yum makecache
执行以下代码设置下载 KLTS 的软件源：
VERSION=1.18.20-lts.2
cat << EOF > /etc/apt/sources.list.d/klts.list
deb [trusted=yes] https://raw.githubusercontent.com/klts-io/kubernetes-lts/deb-v${VERSION} stable main
deb [trusted=yes] https://raw.githubusercontent.com/klts-io/others/deb stable main
EOF
apt-get update
说明：以下加速均来自第三方, 安全和稳定性不做保障, 仅建议测试环境使用 ❗️❗️❗️
执行以下代码设置下载 KLTS 的软件源：
curl https://raw.githubusercontent.com/wzshiming/github-hosts/master/hosts >>/etc/hosts
VERSION=1.18.20-lts.2
cat << EOF > /etc/yum.repos.d/klts.repo
[klts]
name=klts
baseurl=https://raw.githubusercontent.com/klts-io/kubernetes-lts/rpm-v${VERSION}/\$basearch/
enabled=1
gpgcheck=0
[klts-other]
name=klts-others
baseurl=https://raw.githubusercontent.com/klts-io/others/rpm/\$basearch/
enabled=1
gpgcheck=0
EOF
yum makecache
VERSION=1.18.20-lts.2
cat << EOF > /etc/yum.repos.d/klts.repo
[klts]
name=klts
baseurl=https://hub.fastgit.org/klts-io/kubernetes-lts/raw/rpm-v${VERSION}/\$basearch/
enabled=1
gpgcheck=0
[klts-other]
name=klts-others
baseurl=https://hub.fastgit.org/klts-io/others/raw/rpm/\$basearch/
enabled=1
gpgcheck=0
EOF
yum makecache
VERSION=1.18.20-lts.2
cat << EOF > /etc/yum.repos.d/klts.repo
[klts]
name=klts
baseurl=https://ghproxy.com/https://raw.githubusercontent.com/klts-io/kubernetes-lts/rpm-v${VERSION}/\$basearch/
enabled=1
gpgcheck=0
[klts-other]
name=klts-others
baseurl=https://ghproxy.com/https://raw.githubusercontent.com/klts-io/others/rpm/\$basearch/
enabled=1
gpgcheck=0
EOF
yum makecache
VERSION=1.18.20-lts.2
cat << EOF > /etc/yum.repos.d/klts.repo
[klts]
name=klts
baseurl=https://raw.githubusercontents.com/klts-io/kubernetes-lts/rpm-v${VERSION}/\$basearch/
enabled=1
gpgcheck=0
[klts-other]
name=klts-others
baseurl=https://raw.githubusercontents.com/klts-io/others/rpm/\$basearch/
enabled=1
gpgcheck=0
EOF
yum makecache
VERSION=1.18.20-lts.2
cat << EOF > /etc/yum.repos.d/klts.repo
[klts]
name=klts
baseurl=https://raw.staticdn.net/klts-io/kubernetes-lts/rpm-v${VERSION}/\$basearch/
enabled=1
gpgcheck=0
[klts-other]
name=klts-others
baseurl=https://raw.staticdn.net/klts-io/others/rpm/\$basearch/
enabled=1
gpgcheck=0
EOF
yum makecache
说明：以下加速均来自第三方, 安全和稳定性不做保障, 仅建议测试环境使用 ❗️❗️❗️
执行以下代码设置下载 KLTS 的软件源：
curl https://raw.githubusercontent.com/wzshiming/github-hosts/master/hosts >>/etc/hosts
VERSION=1.18.20-lts.2
cat << EOF > /etc/apt/sources.list.d/klts.list
deb [trusted=yes] https://raw.githubusercontent.com/klts-io/kubernetes-lts/deb-v${VERSION} stable main
deb [trusted=yes] https://raw.githubusercontent.com/klts-io/others/deb stable main
EOF
apt-get update
VERSION=1.18.20-lts.2
cat << EOF > /etc/apt/sources.list.d/klts.list
deb [trusted=yes] https://hub.fastgit.org/klts-io/kubernetes-lts/raw/deb-v${VERSION} stable main
deb [trusted=yes] https://hub.fastgit.org/klts-io/others/raw/deb stable main
EOF
apt-get update
VERSION=1.18.20-lts.2
cat << EOF > /etc/apt/sources.list.d/klts.list
deb [trusted=yes] https://ghproxy.com/https://raw.githubusercontent.com/klts-io/kubernetes-lts/deb-v${VERSION} stable main
deb [trusted=yes] https://ghproxy.com/https://raw.githubusercontent.com/klts-io/others/deb stable main
EOF
apt-get update
VERSION=1.18.20-lts.2
cat << EOF > /etc/apt/sources.list.d/klts.list
deb [trusted=yes] https://raw.githubusercontents.com/klts-io/kubernetes-lts/deb-v${VERSION} stable main
deb [trusted=yes] https://raw.githubusercontents.com/klts-io/others/deb stable main
EOF
apt-get update
VERSION=1.18.20-lts.2
cat << EOF > /etc/apt/sources.list.d/klts.list
deb [trusted=yes] https://raw.staticdn.net/klts-io/kubernetes-lts/deb-v${VERSION} stable main
deb [trusted=yes] https://raw.staticdn.net/klts-io/kubernetes-lts/deb stable main
EOF
apt-get update
安装
执行以下命令安装：
yum install kubeadm kubelet kubectl
执行以下命令安装：
apt-get install kubeadm kubelet kubectl
开机自动启动 Kubelet
执行以下命令开机自动启动 Kubelet：
systemctl enable kubelet
拉取依赖镜像
执行以下命令 pull 依赖的镜像：
VERSION=1.18.20-lts.2
REPOS=ghcr.io/klts-io/kubernetes-lts
kubeadm config images pull --image-repository ${REPOS} --kubernetes-version v${VERSION}
执行以下命令 pull 依赖的镜像：
VERSION=1.18.20-lts.2
REPOS=ghcr.m.daocloud.io/klts-io/kubernetes-lts
kubeadm config images pull --image-repository ${REPOS} --kubernetes-version v${VERSION}
后续对 kubeadm 的操作都需要加上 --image-repository 和 --kubernetes-version 以主动指定镜像。
初始化控制面节点
执行以下命令初始化控制面的节点：
VERSION=1.18.20-lts.2
REPOS=ghcr.io/klts-io/kubernetes-lts
kubeadm init --image-repository ${REPOS} --kubernetes-version v${VERSION}
执行以下命令初始化控制面的节点：
VERSION=1.18.20-lts.2
REPOS=ghcr.m.daocloud.io/klts-io/kubernetes-lts
kubeadm init --image-repository ${REPOS} --kubernetes-version v${VERSION}
有关更多安装说明，请参阅 Kubernetes 操作指南。
4 - 脚本一键安装
KLTS 提供了以下脚本自动完成安装流程。
wget https://github.com/klts-io/klts/raw/main/install.sh
chmod +x install.sh
./install.sh
Usage: ./install.sh [OPTIONS]
-h, --help : Display this help and exit
--kubernetes-container-registry=ghcr.io/klts-io/kubernetes-lts : Kubernetes container registry
--kubernetes-version=1.18.20-lts.1 : Kubernetes version to install
--containerd-version=1.3.10-lts.0 : Containerd version to install
--runc-version=1.0.2-lts.0 : Runc version to install
--kubernetes-rpm-source=https://github.com/klts-io/kubernetes-lts/raw/rpm-v1.18.20-lts.2 : Kubernetes RPM source
--containerd-rpm-source=https://github.com/klts-io/containerd-lts/raw/rpm-v1.3.10-lts.0 : Containerd RPM source
--runc-rpm-source=https://github.com/klts-io/runc-lts/raw/rpm-v1.0.2-lts.0 : Runc RPM source
--others-rpm-source=https://github.com/klts-io/others/raw/rpm : Other RPM source
--kubernetes-deb-source=https://github.com/klts-io/kubernetes-lts/raw/deb-v1.18.20-lts.2 : Kubernetes DEB source
--containerd-deb-source=https://github.com/klts-io/containerd-lts/raw/deb-v1.3.10-lts.0 : Containerd DEB source
--runc-deb-source=https://github.com/klts-io/runc-lts/raw/deb-v1.0.2-lts.0 : Runc DEB source
--others-deb-source=https://github.com/klts-io/others/raw/deb : Other DEB source
--focus=enable-iptables-discover-bridged-traffic,disable-swap,disable-selinux,setup-source,install-kubernetes,install-containerd,install-runc,install-crictl,install-cniplugins,setup-crictl-config,setup-containerd-cni-config,setup-kubelet-config,setup-containerd-config,daemon-reload,start-containerd,status-containerd,enable-containerd,start-kubelet,status-kubelet,enable-kubelet,images-pull,control-plane-init,status-nodes,show-join-command : Focus on specific step
--skip='' : Skip on specific step
5 - Kubernetes
5.1 - 修复的漏洞
5.1.1 - CVE-2021-25741
漏洞详情这是一个权限访问相关的卷安全性问题。用户可以在创建的容器中通过 subpath 的卷挂载方式访问到该卷挂载目录之外的文件和目录，包括主机的文件系统。
漏洞影响
该漏洞影响 kubelet 相关行为，对于严格限制 hostPath 创建行为的集群管理员来说问题尤为严重。
漏洞评分
该漏洞为中危漏洞， CVSS 评分为 5.5。
防范措施
对于不想升级 kubelet 的用户来说，可以有两种防范措施：
- 禁止
kubelet，kube-apiserver的VolumeSubpath功能，并且移除所有正在使用该功能的pod。 - 使用
admission control防止信任度较低的用户使用root权限运行容器。
官方修复的版本
- v1.22.2
- v1.21.5
- v1.20.11
- v1.19.15
KLTS 修复的版本
- v1.18.20-lts.1 kubernetes/kubernetes#104253
- v1.17.17-lts.1 TODO
- v1.16.15-lts.1 TODO
- v1.15.12-lts.1 TODO
- v1.14.10-lts.1 TODO
- v1.13.12-lts.1 TODO
- v1.12.10-lts.1 TODO
- v1.11.10-lts.1 TODO
- v1.10.13-lts.1 TODO
5.1.2 - CVE-2021-3121
漏洞详情存在该漏洞的程序可能会因为处理了包含恶意 Protobuf 消息而崩溃。如果您使用的 Gogo Protobuf 版本过低，可能存在该漏洞。
漏洞影响
Kubernetes 系统组件由于自身有应对崩溃的恢复机制，当遇到恶意提交的 Protobuf 消息时不会中断服务，所以不在该漏洞的影响范围内。
在应用系统中程序接收处理 Protobuf 消息时，如果组件没有应对崩溃的恢复机制，那么这类程序都在该漏洞影响范围内，且被恶意攻击时服务可能会中断。
Kubernetes 社区经过测试验证 API Server 不受该漏洞的影响，但为了避免您受到该安全漏洞隐患的影响，社区对相关 Protobuf 文件进行了升级。
防范措施
如果在您的应用系统代码中使用了自动生成的 Protobuf 消息，并且发现相关组件因为以下异常退出，则可能存在该漏洞。
panic: runtime error: index out of range [-9223372036854775804]
goroutine 1 [running]:
v1.(*MessageName).Unmarshal(0xc00006f1e8, 0xc0000281a8, 0xa, 0x10, 0xc00006f1b8, 0x1)
.../protofile.pb.go:250 +0xb86
如果您使用了 Protobuf 消息的相关组件，推荐将 Gogo Protobuf 编译器升级到漏洞修复版本（v1.3.2 或更高的版本），再基于升级后的 Protobuf 编译器重新生成相关的 Protobuf 消息。
官方修复的版本
- v1.21.1
- v1.20.7
- v1.19.11
- v1.18.19
KLTS 修复的版本
- v1.17.17-lts.1 kubernetes/kubernetes#101327
- v1.16.15-lts.1 kubernetes/kubernetes#101327
- v1.15.12-lts.1 kubernetes/kubernetes#101327
- v1.14.10-lts.1 kubernetes/kubernetes#101327
- v1.13.12-lts.1 kubernetes/kubernetes#101327
- v1.12.10-lts.1 kubernetes/kubernetes#101327
- v1.11.10-lts.1 kubernetes/kubernetes#101327
- v1.10.13-lts.1 kubernetes/kubernetes#101327
5.1.3 - CVE-2020-8559
漏洞详情这是 kube-apiserver 组件的安全漏洞，攻击者可以通过截取某些发送至节点 kubelet 的升级请求，通过请求中原有的访问凭据转发请求至其他目标节点，从而造成节点权限提升的漏洞。
漏洞影响
由于 kube-apiserver 在升级请求的代理后端中允许将请求传播回源客户端，所以攻击者可以通过截取某些发送至节点 kubelet 的升级请求，然后利用请求中原有的访问凭据转发请求至其他目标节点，从而造成被攻击节点出现权限提升的漏洞。
漏洞评分
该漏洞为中危漏洞， CVSS 评分为 6.4。
如果有多个集群共享使用了相同的 CA 和认证凭证，攻击者可以利用此漏洞攻击其他集群，这种情况下该漏洞为高危漏洞。
防范措施
对于集群内跨节点的攻击，建议您采取以下安全防范措施：
- 及时吊销可能泄露的
kubeconfig凭证，并且遵循权限最小化原则，收敛子账号不必要的pods/exec、pods/attach、pods/portforward和proxy类型的资源模型RBAC权限。
官方修复的版本
- v1.18.6
- v1.17.9
- v1.16.13
KLTS 修复的版本
5.1.4 - CVE-2020-8558
漏洞详情kube-proxy 组件在 iptables 和 ipvs 模式下均需要设置内核参数 net.ipv4.conf.all.route_localnet=1， 从而允许本地回环访问。攻击者可能通过共享主机网络的容器，或在集群节点访问同一个 LAN 或二层网络下的相邻节点上绑定监听本地 127.0.0.1 端口的 TCP/UDP 服务，从而获取接口信息。如果您的服务没有设置必要的安全认证，可能会造成信息泄露风险。
漏洞影响
当攻击者拥有主机网络配置能力或运行在一个具备了 CAP_NET_RAW 能力的容器实例时，就可以获取在目标节点上监听 127.0.0.1 的服务 socket 信息。如果在目标主机上存在 127.0.0.1 可以访问且不需要任何认证鉴权的暴露服务，那么该服务信息就能被攻击者获取。
漏洞评分
- 如果集群
API Server开启了非认证端口（默认 8080），那么攻击者可能获取到API Server接口相关信息，威胁等级为高危漏洞，评分为 8.8 分。 - 如果集群
API Server默认关闭了非认证端口，威胁等级为中危漏洞，评分为 5.4 分。
防范措施
建议您采取以下安全防范措施：
如果业务容器需使用主机网络模式且又在非安全端口上监听，则可以通过在节点上手动添加 iptables 规则来缓解此漏洞。
执行以下命令在集群中配置 iptables 规则，用于拒绝非本地对 127.0.0.1 的访问流量：
iptables -I INPUT --dst 127.0.0.0/8 ! --src 127.0.0.0/8 -m conntrack ! --ctstate RELATED,ESTABLISHED,DNAT -j DROP
如果集群不需要开启 API Server 不安全端口，可以将 --insecure-port=0 添加到 kubernetes API 服务器命令行来禁用端口。
如集群内运行不受信任的容器，可以禁止 Container 开启 CAP_NET_RAW 能力，在 pod spec 中关闭 Container 的 CAP_NET_RAW 能力。
securityContext:
capabilities:
drop:
- "NET_RAW"
通过 PodSecurityPolicy 策略限制部署特权或共享主机网络容器，另外可以通过在策略中配置 requiredDropCapabilities 强制容器部署关闭 CAP_NET_RAW 能力。
官方修复的版本
- v1.18.4
- v1.17.7
- v1.16.11
KLTS 修复的版本
5.1.5 - CVE-2020-8552
漏洞详情此漏洞可能使 API Server 易于遭受 API 请求成功造成的 DoS（拒绝服务攻击）。
漏洞影响
API Server 易于遭受 API 请求成功造成的 DoS（拒绝服务攻击）。
官方修复的版本
- v1.17.3
- v1.16.7
- v1.15.10
KLTS 修复的版本
5.1.6 - CVE-2019-1002101
漏洞详情此漏洞可能允许攻击者在 kubectl cp 命令执行解压过程中修改或监控符号链接头同名目录下的任意文件，从而造成破坏。
漏洞影响
kubectl cp 命令允许用户在容器和用户机器之间拷贝文件，攻击者可能通过在镜像或运行容器中植入带有符号链接（symbolic links）头的恶意 tar 包，在 cp 命令执行解压过程中修改或监控符号链接头同名目录下的任意文件，从而造成破坏。
官方修复的版本
- v1.14.1
- v1.13.6
- v1.12.8
- v1.11.10
KLTS 修复的版本
5.1.7 - CVE-2019-11251
漏洞详情此漏洞可能允许攻击者利用 kubectl cp 命令，采用路径遍历(Path Traversal)的方式将容器 tar 包中的恶意文件写入所在主机上的任何路径，该过程仅受本地用户的系统权限限制。
漏洞影响
该漏洞与不久前的 CVE-2019-1002101、CVE-2019-11246、CVE-2019-11249 漏洞影响相似。
kubectl cp 命令用于用户容器和主机之间的文件拷贝，当从容器中拷贝文件时，Kubernetes 首先会在容器中执行 tar 命令创建相应的归档文件，然后发送给客户端，然后 kubectl 会在用户主机上进行相应解压操作。
如果容器 tar 包中包含恶意文件，当攻击者具有 kubectl cp 命令的执行权限时，可以利用路径遍历(Path Traversal)。
官方修复的版本
- v1.15.4
- v1.14.7
- v1.13.11
KLTS 修复的版本
5.1.8 - CVE-2019-11248
漏洞详情可以通过健康检查的端口访问 /debug/pprof。
漏洞影响
该漏洞存在于 Kubelet 中，用于性能调试的 /debug/pprof 跟健康检查端口 /healthz 绑定在一起，其中 /debug/pprof 会进行安全认证，但 /healthz 接口并不进行认证鉴权。所以如果 Kubelet 的 healthz 地址未使用 localhost，则会存在泄露机器敏感信息的风险。
官方修复的版本
- v1.14.4
- v1.13.8
- v1.12.10
KLTS 修复的版本
5.1.9 - CVE-2019-11247
漏洞详情API Server 允许通过错误的范围访问自定义的资源。
漏洞影响
如果某个用户请求的资源已划分到命名空间，Kubernetes kube-apiserver 将错误地允许该用户访问集群范围内的自定义资源。
以这种方式访问资源将等同于授予命名空间内所有角色及其权限，这意味着本来只能访问命名空间中一个资源的用户将能够创建、查看、更新或删除整个集群范围的资源（具体取决于其命名空间角色权限）。
官方修复的版本
- v1.12.12
KLTS 修复的版本
5.1.10 - CVE-2019-11246
漏洞详情此漏洞可能允许攻击者利用 kubectl cp 命令，采用路径遍历 (Path Traversal) 的方式将容器 tar 包中的恶意文件写入所在主机上的任何路径，该过程仅受本地用户的系统权限限制。
漏洞影响
该漏洞与不久前的 CVE-2019-1002101 漏洞影响相似。
kubectl cp 命令用于用户容器和主机之间的文件拷贝。当从容器中拷贝文件时，Kubernetes 首先会在容器中执行 tar 命令创建相应的归档文件，然后发送给客户端，kubectl 会在用户主机上进行相应解压操作。
如果容器 tar 包中包含恶意文件，当攻击者具有 kubectl cp 命令的执行权限时，可以利用路径遍历 (Path Traversal) 方式将恶意文件写入任意路径。
官方修复的版本
- v1.14.3
- v1.13.7
- v1.12.10
KLTS 修复的版本
5.1.11 - CVE-2019-11245
漏洞详情这是一个提权漏洞，通常以容器 Dockerfile 中指定的 USER 运行的容器，在容器重启时或者如果镜像先前被拉到节点时，都将以 root(uid 0) 身份运行。
漏洞影响
所有未指定 mustRunAsNonRoot: true 的 Pod，在容器重启时或者如果镜像先前被拉到节点时，都将以 root(uid 0) 身份运行。
防范措施
为 Pod 指定 mustRunAsNonRoot: true。
官方修复的版本
- v1.14.3
- v1.13.7
KLTS 修复的版本
5.1.12 - CVE-2019-11249
漏洞详情此漏洞可能允许攻击者利用 kubectl cp 命令，采用路径遍历(Path Traversal)的方式将容器 tar 包中的恶意文件写入所在主机上的任何路径，该过程仅受本地用户的系统权限限制。
漏洞影响
该漏洞与不久前的 CVE-2019-1002101、CVE-2019-11246 漏洞影响相似。
kubectl cp 命令用于用户容器和主机之间的文件拷贝，当从容器中拷贝文件时，Kubernetes 首先会在容器中执行 tar 命令创建相应的归档文件，然后发送给客户端，然后 kubectl 会在用户主机上进行相应解压操作。
如果容器 tar 包中包含恶意文件，当攻击者具有 kubectl cp 命令的执行权限时，可以利用路径遍历 (Path Traversal)。
官方修复的版本
- v1.15.2
- v1.14.5
- v1.13.9
KLTS 修复的版本
5.1.13 - nokmem
Bug 详情节点磁盘充足但是一直报磁盘不足无法创建 Pod。
Bug 影响
节点长期使用的时候提示剩余空间不足的错误，报错信息如下所示：
mkdir: cannot create directory '/sys/fs/cgroup/memory/8': No space left on device
节点磁盘充足但是一直报和这个错误, 并且创建 Pod 总是失败，这是一个潜在的“定时炸弹”。
所有使用低版本内核的环境以及 Kubernetes 1.21 之前的版本都会受到影响，在 runc 1.0.0-rc94 (opencontainers/runc#2840) 进行了修复(被直接移除)。
防范措施
- 升级系统内核
- Kubernetes 1.14 到 1.20
- 重新构建 Kubelet 带上
-tags=nokmem
- 重新构建 Kubelet 带上
- Kubernetes 1.14 以下
- 有关硬编码，请参考 nokmem.1.13.patch
- Kubernetes 1.21 及以上
- 不受影响
KLTS 修复的版本
- /docs/kubernetes/releases/v1.20/v1.20.15-lts.1/ nokmem.1.20.patch
- /docs/kubernetes/releases/v1.19/v1.19.16-lts.1/ nokmem.1.20.patch
- v1.18.20-lts.1 nokmem.1.20.patch
- v1.17.17-lts.1 nokmem.1.20.patch
- v1.16.15-lts.1 nokmem.1.20.patch
- v1.15.12-lts.1 nokmem.1.20.patch
- v1.14.10-lts.1 nokmem.1.20.patch
- v1.13.12-lts.1 nokmem.1.13.patch
- v1.12.10-lts.1 nokmem.1.13.patch
- v1.11.10-lts.1 nokmem.1.13.patch
- v1.10.13-lts.1 nokmem.1.13.patch
5.2 - 版本日志
5.2.1 - v1.28
5.2.1.1 - v1.28.15-lts.0
这是 KLTS 发布的第一个 v1.28.15 修复版本。
补丁
- 只是跑通了 CI 没做任何修复
5.2.2 - v1.27
5.2.2.1 - v1.27.16-lts.0
这是 KLTS 发布的第一个 v1.27.16 修复版本。
补丁
- 只是跑通了 CI 没做任何修复
5.2.3 - v1.26
5.2.3.1 - v1.26.15-lts.0
这是 KLTS 发布的第一个 v1.26.15 修复版本。
补丁
- 只是跑通了 CI 没做任何修复
5.2.4 - v1.25
5.2.4.1 - v1.25.16-lts.0
这是 KLTS 发布的第一个 v1.25.16 修复版本。
补丁
- 只是跑通了 CI 没做任何修复
5.2.5 - v1.24
5.2.5.1 - v1.24.17-lts.0
这是 KLTS 发布的第一个 v1.24.17 修复版本。
补丁
- 只是跑通了 CI 没做任何修复
5.2.6 - v1.23
5.2.6.1 - v1.23.17-lts.0
这是 KLTS 发布的第一个 v1.23.17 修复版本。
补丁
- 只是跑通了 CI 没做任何修复
5.2.6.2 - v1.23.4-lts.1
这是 KLTS 发布的第一个 v1.23.5 修复版本。
补丁
- 只是跑通了 CI 没做任何修复
5.2.7 - v1.22
5.2.7.1 - v1.22.17-lts.0
这是 KLTS 发布的第一个 v1.22.17 修复版本。
补丁
- 只是跑通了 CI 没做任何修复
5.2.7.2 - v1.22.8-lts.1
这是 KLTS 发布的第一个 v1.22.8 修复版本。
补丁
- 只是跑通了 CI 没做任何修复
5.2.8 - v1.21
5.2.8.1 - v1.21.11-lts.1
这是 KLTS 发布的第一个 v1.21.11 修复版本。
补丁
- 只是跑通了 CI 没做任何修复
5.2.9 - v1.20
5.2.10 - v1.19
5.2.10.1 - v1.19.16-lts.3
这是 KLTS 发布的第三个 v1.19.16 修复版本。
补丁
- nokmem
节点磁盘充足但是一直报磁盘不足无法创建
Pod。 - /docs/kubernetes/patches/cve-2020-8554/
5.2.11 - v1.18
5.2.11.1 - v1.18.20-lts.1
这是 KLTS 发布的第一个 v1.18.20 修复版本。
补丁
- nokmem
节点磁盘充足但是一直报磁盘不足无法创建
Pod。 - CVE-2021-25741
这是一个权限访问相关的卷安全性问题。用户可以在创建的容器中通过
subpath的卷挂载方式访问到该卷挂载目录之外的文件和目录，包括主机的文件系统。
5.2.11.2 - v1.18.20-lts.2
这是 KLTS 发布的第二个 v1.18.20 修复版本。
补丁
- 修复问题: kubelet 重启后创建的新 pod 缺少环境变量 KUBERNETES_SERVICE_HOST
5.2.12 - v1.17
5.2.12.1 - v1.17.17-lts.1
这是 KLTS 发布的第一个 v1.17.17 修复版本。
补丁
- CVE-2021-3121
存在该漏洞的程序可能会因为处理了包含恶意
Protobuf消息而崩溃。如果您使用的Gogo Protobuf版本过低，可能存在该漏洞。 - nokmem
节点磁盘充足但是一直报磁盘不足无法创建
Pod。
5.2.13 - v1.16
5.2.13.1 - v1.16.15-lts.1
这是 KLTS 发布的第一个 v1.16.15 修复版本。
补丁
- CVE-2021-3121
存在该漏洞的程序可能会因为处理了包含恶意
Protobuf消息而崩溃。如果您使用的Gogo Protobuf版本过低，可能存在该漏洞。 - nokmem
节点磁盘充足但是一直报磁盘不足无法创建
Pod。
5.2.14 - v1.15
5.2.14.1 - v1.15.12-lts.1
这是 KLTS 发布的第一个 v1.15.12 修复版本。
补丁
- CVE-2020-8558
kube-proxy组件在iptables和ipvs模式下均需要设置内核参数net.ipv4.conf.all.route_localnet=1， 从而允许本地回环访问。攻击者可能通过共享主机网络的容器，或在集群节点访问同一个 LAN 或二层网络下的相邻节点上绑定监听本地127.0.0.1端口的 TCP/UDP 服务，从而获取接口信息。如果您的服务没有设置必要的安全认证，可能会造成信息泄露风险。 - CVE-2021-3121
存在该漏洞的程序可能会因为处理了包含恶意
Protobuf消息而崩溃。如果您使用的Gogo Protobuf版本过低，可能存在该漏洞。 - nokmem
节点磁盘充足但是一直报磁盘不足无法创建
Pod。
5.2.15 - v1.14
5.2.15.1 - v1.14.10-lts.1
这是 KLTS 发布的第一个 v1.14.10 修复版本。
补丁
- CVE-2020-8552
此漏洞可能使
API Server易于遭受API请求成功造成的DoS（拒绝服务攻击）。 - CVE-2020-8558
kube-proxy组件在iptables和ipvs模式下均需要设置内核参数net.ipv4.conf.all.route_localnet=1， 从而允许本地回环访问。攻击者可能通过共享主机网络的容器，或在集群节点访问同一个 LAN 或二层网络下的相邻节点上绑定监听本地127.0.0.1端口的 TCP/UDP 服务，从而获取接口信息。如果您的服务没有设置必要的安全认证，可能会造成信息泄露风险。 - CVE-2020-8559
这是
kube-apiserver组件的安全漏洞，攻击者可以通过截取某些发送至节点kubelet的升级请求，通过请求中原有的访问凭据转发请求至其他目标节点，从而造成节点权限提升的漏洞。 - CVE-2021-3121
存在该漏洞的程序可能会因为处理了包含恶意
Protobuf消息而崩溃。如果您使用的Gogo Protobuf版本过低，可能存在该漏洞。 - nokmem
节点磁盘充足但是一直报磁盘不足无法创建
Pod。
5.2.16 - v1.13
5.2.16.1 - v1.13.12-lts.1
这是 KLTS 发布的第一个 v1.13.12 修复版本。
补丁
- CVE-2020-8552
此漏洞可能使
API Server易于遭受API请求成功造成的DoS（拒绝服务攻击）。 - CVE-2020-8558
kube-proxy组件在iptables和ipvs模式下均需要设置内核参数net.ipv4.conf.all.route_localnet=1， 从而允许本地回环访问。攻击者可能通过共享主机网络的容器，或在集群节点访问同一个 LAN 或二层网络下的相邻节点上绑定监听本地127.0.0.1端口的 TCP/UDP 服务，从而获取接口信息。如果您的服务没有设置必要的安全认证，可能会造成信息泄露风险。 - TODO CVE-2020-8559
这是
kube-apiserver组件的安全漏洞，攻击者可以通过截取某些发送至节点kubelet的升级请求，通过请求中原有的访问凭据转发请求至其他目标节点，从而造成节点权限提升的漏洞。 - CVE-2021-3121
存在该漏洞的程序可能会因为处理了包含恶意
Protobuf消息而崩溃。如果您使用的Gogo Protobuf版本过低，可能存在该漏洞。 - nokmem
节点磁盘充足但是一直报磁盘不足无法创建
Pod。
5.2.17 - v1.12
5.2.17.1 - v1.12.10-lts.1
这是 KLTS 发布的第一个 v1.12.10 修复版本。
补丁
- CVE-2019-11245
这是一个提权漏洞，通常以容器
Dockerfile中指定的USER运行的容器，在容器重启时或者如果镜像先前被拉到节点时，都将以root(uid 0) 身份运行。 - CVE-2019-11247
API Server允许通过错误的范围访问自定义的资源。 - CVE-2019-11249
此漏洞可能允许攻击者利用
kubectl cp命令，采用路径遍历(Path Traversal)的方式将容器tar包中的恶意文件写入所在主机上的任何路径，该过程仅受本地用户的系统权限限制。 - CVE-2019-11251
此漏洞可能允许攻击者利用
kubectl cp命令，采用路径遍历(Path Traversal)的方式将容器tar包中的恶意文件写入所在主机上的任何路径，该过程仅受本地用户的系统权限限制。 - CVE-2020-8552
此漏洞可能使
API Server易于遭受API请求成功造成的DoS（拒绝服务攻击）。 - CVE-2020-8558
kube-proxy组件在iptables和ipvs模式下均需要设置内核参数net.ipv4.conf.all.route_localnet=1， 从而允许本地回环访问。攻击者可能通过共享主机网络的容器，或在集群节点访问同一个 LAN 或二层网络下的相邻节点上绑定监听本地127.0.0.1端口的 TCP/UDP 服务，从而获取接口信息。如果您的服务没有设置必要的安全认证，可能会造成信息泄露风险。 - TODO CVE-2020-8559
这是
kube-apiserver组件的安全漏洞，攻击者可以通过截取某些发送至节点kubelet的升级请求，通过请求中原有的访问凭据转发请求至其他目标节点，从而造成节点权限提升的漏洞。 - CVE-2021-3121
存在该漏洞的程序可能会因为处理了包含恶意
Protobuf消息而崩溃。如果您使用的Gogo Protobuf版本过低，可能存在该漏洞。 - nokmem
节点磁盘充足但是一直报磁盘不足无法创建
Pod。
5.2.18 - v1.11
5.2.18.1 - v1.11.10-lts.1
这是 KLTS 发布的第一个 v1.11.10 修复版本。
补丁
- CVE-2019-11245
这是一个提权漏洞，通常以容器
Dockerfile中指定的USER运行的容器，在容器重启时或者如果镜像先前被拉到节点时，都将以root(uid 0) 身份运行。 - CVE-2019-11246
此漏洞可能允许攻击者利用
kubectl cp命令，采用路径遍历 (Path Traversal) 的方式将容器tar包中的恶意文件写入所在主机上的任何路径，该过程仅受本地用户的系统权限限制。 - CVE-2019-11247
API Server允许通过错误的范围访问自定义的资源。 - CVE-2019-11248
可以通过健康检查的端口访问
/debug/pprof。 - CVE-2019-11249
此漏洞可能允许攻击者利用
kubectl cp命令，采用路径遍历(Path Traversal)的方式将容器tar包中的恶意文件写入所在主机上的任何路径，该过程仅受本地用户的系统权限限制。 - CVE-2019-11251
此漏洞可能允许攻击者利用
kubectl cp命令，采用路径遍历(Path Traversal)的方式将容器tar包中的恶意文件写入所在主机上的任何路径，该过程仅受本地用户的系统权限限制。 - CVE-2020-8552
此漏洞可能使
API Server易于遭受API请求成功造成的DoS（拒绝服务攻击）。 - CVE-2020-8558
kube-proxy组件在iptables和ipvs模式下均需要设置内核参数net.ipv4.conf.all.route_localnet=1， 从而允许本地回环访问。攻击者可能通过共享主机网络的容器，或在集群节点访问同一个 LAN 或二层网络下的相邻节点上绑定监听本地127.0.0.1端口的 TCP/UDP 服务，从而获取接口信息。如果您的服务没有设置必要的安全认证，可能会造成信息泄露风险。 - TODO CVE-2020-8559
这是
kube-apiserver组件的安全漏洞，攻击者可以通过截取某些发送至节点kubelet的升级请求，通过请求中原有的访问凭据转发请求至其他目标节点，从而造成节点权限提升的漏洞。 - CVE-2021-3121
存在该漏洞的程序可能会因为处理了包含恶意
Protobuf消息而崩溃。如果您使用的Gogo Protobuf版本过低，可能存在该漏洞。 - nokmem
节点磁盘充足但是一直报磁盘不足无法创建
Pod。
5.2.19 - v1.10
5.2.19.1 - v1.10.13-lts.1
这是 KLTS 发布的第一个 v1.10.13 修复版本。
补丁
- CVE-2019-11245
这是一个提权漏洞，通常以容器
Dockerfile中指定的USER运行的容器，在容器重启时或者如果镜像先前被拉到节点时，都将以root(uid 0) 身份运行。 - CVE-2019-1002101
此漏洞可能允许攻击者在
kubectl cp命令执行解压过程中修改或监控符号链接头同名目录下的任意文件，从而造成破坏。 - CVE-2019-11246
此漏洞可能允许攻击者利用
kubectl cp命令，采用路径遍历 (Path Traversal) 的方式将容器tar包中的恶意文件写入所在主机上的任何路径，该过程仅受本地用户的系统权限限制。 - TODO CVE-2019-11247
API Server允许通过错误的范围访问自定义的资源。 - CVE-2019-11248
可以通过健康检查的端口访问
/debug/pprof。 - CVE-2019-11249
此漏洞可能允许攻击者利用
kubectl cp命令，采用路径遍历(Path Traversal)的方式将容器tar包中的恶意文件写入所在主机上的任何路径，该过程仅受本地用户的系统权限限制。 - CVE-2019-11251
此漏洞可能允许攻击者利用
kubectl cp命令，采用路径遍历(Path Traversal)的方式将容器tar包中的恶意文件写入所在主机上的任何路径，该过程仅受本地用户的系统权限限制。 - CVE-2020-8552
此漏洞可能使
API Server易于遭受API请求成功造成的DoS（拒绝服务攻击）。 - TODO CVE-2020-8558
kube-proxy组件在iptables和ipvs模式下均需要设置内核参数net.ipv4.conf.all.route_localnet=1， 从而允许本地回环访问。攻击者可能通过共享主机网络的容器，或在集群节点访问同一个 LAN 或二层网络下的相邻节点上绑定监听本地127.0.0.1端口的 TCP/UDP 服务，从而获取接口信息。如果您的服务没有设置必要的安全认证，可能会造成信息泄露风险。 - TODO CVE-2020-8559
这是
kube-apiserver组件的安全漏洞，攻击者可以通过截取某些发送至节点kubelet的升级请求，通过请求中原有的访问凭据转发请求至其他目标节点，从而造成节点权限提升的漏洞。 - CVE-2021-3121
存在该漏洞的程序可能会因为处理了包含恶意
Protobuf消息而崩溃。如果您使用的Gogo Protobuf版本过低，可能存在该漏洞。 - nokmem
节点磁盘充足但是一直报磁盘不足无法创建
Pod。
6 - Containerd
6.1 - 修复的漏洞
6.1.1 - CVE-2021-41103
在容器根目录和一些系统插件中缺少必要的权限约束时，可使一个非特权的主机 Linux 用户拥有遍历容器文件系统并执行目标程序的权限。
漏洞影响
在多租户场景下，如果集群节点中的容器包含扩展权限（例如 setuid），非特权的 Linux 用户可能发现并执行该程序。如果非特权的主机 Linux 用户 UID 碰撞到了容器中执行程序的所属用户或组，这个非特权的 Linux 用户可以读写该文件从而导致越权访问。
漏洞评分
该漏洞为高危漏洞， CVSS 评分为 7.2。
防范措施
保证集群节点登录用户都是可信用户，限制非受信用户对集群节点的访问权限。 收敛容器 bundles 目录中不必要的扩展权限。
官方修复的版本
- v1.4.11
- v1.5.7
KLTS 修复的版本
6.2 - 版本日志
6.2.1 - v1.3
6.2.1.1 - v1.3.10-lts.1
这是 KLTS Containerd 发布的第一个 v1.3.10 修复版本。
补丁
- CVE-2021-41103
在容器根目录和一些系统插件中缺少必要的权限约束时，可使一个非特权的主机 Linux 用户拥有遍历容器文件系统并执行目标程序的权限。
7 - 添加 CVE 补丁到 klts
CVE 在 kubernetes 社区是持续更新的，我们需要在维护的所有版本中修复更新的 CVE 漏洞。基于源 patch 文件在低于此 patch 的版本更新出各个版本对应的 patch 文件。klts 有自动更新 patch 的功能，我们只需要解决冲突，保证代码的有效性和可用性。
下面将介绍如何把在 klts 中添加一个 CVE 补丁。
- 先指定需要修复的 CVE 脚本，修改
release.yaml，先添加对应 CVE 的patch来源，此路径可以是一个链接，也可以下载到 /patches 目录，Score是代表这个 CVE 的优先级，数值越高说明对安全的影响更大。< k8s1.13表示在1.13（1.12，1.11，1.10）以下的版本都需要被解决漏洞。
在1.12版本中运用 CVE-2019-11253 patch 文件：
- name: v1.12.10-lts.1
base_release: v1.12.10-ci
must: true
patches:
- CVE-2019-11253
# CVSS Score 5.0, < k8s1.13, https://www.cvedetails.com/cve/CVE-2019-11253/
# TODO
- name: CVE-2019-11253
patch:
- https://github.com/kubernetes/kubernetes/pull/83436.patch
- 检查
v1.12.10-lts.1是否能够完全运用此 patch，如果有冲突，将会手动去解决冲突代码。
~/workspace/kubernetes-lts: main ± : make v1.12.10-lts.1
Checkout to v1.12.10-lts.1
./hack/checkout.sh v1.12.10-lts.1
remote: Enumerating objects: 77218, done.
remote: Counting objects: 100% (29330/29330), done.
remote: Compressing objects: 100% (11622/11622), done.
remote: Total 14180 (delta 7451), reused 5859 (delta 2116), pack-reused 0
Receiving objects: 100% (14180/14180), 15.77 MiB | 1.90 MiB/s, done.
Resolving deltas: 100% (7451/7451), completed with 4241 local objects.
Reset branch 'tag-v1.12.10'
如果输出下面的情况则表示这些文件有冲突：
To restore the original branch and stop patching, run "git am --abort".
+++ Conflicts detected:
UU Godeps/Godeps.json
UU staging/src/k8s.io/api/Godeps/Godeps.json
UU staging/src/k8s.io/apiextensions-apiserver/Godeps/Godeps.json
UU staging/src/k8s.io/apimachinery/Godeps/Godeps.json
UU staging/src/k8s.io/apiserver/Godeps/Godeps.json
UU staging/src/k8s.io/cli-runtime/Godeps/Godeps.json
UU staging/src/k8s.io/client-go/Godeps/Godeps.json
UU staging/src/k8s.io/csi-api/Godeps/Godeps.json
UU staging/src/k8s.io/kube-aggregator/Godeps/Godeps.json
UU staging/src/k8s.io/metrics/Godeps/Godeps.json
UU staging/src/k8s.io/sample-apiserver/Godeps/Godeps.json
UU staging/src/k8s.io/sample-cli-plugin/Godeps/Godeps.json
UU staging/src/k8s.io/sample-controller/Godeps/Godeps.json
UU vendor/gopkg.in/yaml.v2/decode.go
UU vendor/gopkg.in/yaml.v2/encode.go
Aborting.
+++ Aborting in-progress git am.
+++ Returning you to the tag-v1.12.10 branch and cleaning up.
make: *** [v1.12.10-lts.1] Error 1
如果出现没法读取到某一个 patch 文件，请确保源 patch 文件正常下载到
/tmp目录，请重新执行make命令。
- 根据输出的信息，重新修改
1.12的 patch 信息：
+++ About to attempt patch. To reattempt:
$ git am -3 /path/to/kubernetes-lts/tmp/83436.patch
Applying: bump gopkg.in/yaml.v2 v2.2.4
Using index info to reconstruct a base tree...
M Godeps/Godeps.json
M staging/src/k8s.io/api/Godeps/Godeps.json
M staging/src/k8s.io/apiextensions-apiserver/Godeps/Godeps.json
M staging/src/k8s.io/apimachinery/Godeps/Godeps.json
M staging/src/k8s.io/apiserver/Godeps/Godeps.json
M staging/src/k8s.io/cli-runtime/Godeps/Godeps.json
M staging/src/k8s.io/client-go/Godeps/Godeps.json
A staging/src/k8s.io/cloud-provider/Godeps/Godeps.json
M staging/src/k8s.io/csi-api/Godeps/Godeps.json
M staging/src/k8s.io/kube-aggregator/Godeps/Godeps.json
M staging/src/k8s.io/metrics/Godeps/Godeps.json
M staging/src/k8s.io/sample-apiserver/Godeps/Godeps.json
M staging/src/k8s.io/sample-cli-plugin/Godeps/Godeps.json
M staging/src/k8s.io/sample-controller/Godeps/Godeps.json
M vendor/gopkg.in/yaml.v2/decode.go
M vendor/gopkg.in/yaml.v2/encode.go
M vendor/gopkg.in/yaml.v2/resolve.go
M vendor/gopkg.in/yaml.v2/scannerc.go
将 patch 复制到/patches目录：
cp /path/to/kubernetes-lts/tmp/83436.patch patches/CVE-2019-11253.1.12.patch
重新修改 release.yaml 文件：
- name: v1.12.10-lts.1
base_release: v1.12.10-ci
must: true
patches:
- CVE-2019-11253.1.12
# CVSS Score 5.0, < k8s1.13, https://www.cvedetails.com/cve/CVE-2019-11253/
# TODO
- name: CVE-2019-11253
patch:
- https://github.com/kubernetes/kubernetes/pull/83436.patch
- name: CVE-2019-11253.1.12
patch:
- patches/CVE-2019-11253.1.12.patch
- 手动解决冲突文件，请注意手动解决并不是只是简单的代码替换，要满足下面几个条件：
-
采用 patch 修改的内容
-
上下文没有语法错误
-
必须能通过测试用例
执行下面命令解决冲突文件：
QUIET=n ./hack/format_patch.sh patches/CVE-2019-11253.1.12.patch
...
+++ Conflicts detected:
UU Godeps/Godeps.json
UU staging/src/k8s.io/api/Godeps/Godeps.json
UU staging/src/k8s.io/apiextensions-apiserver/Godeps/Godeps.json
UU staging/src/k8s.io/apimachinery/Godeps/Godeps.json
UU staging/src/k8s.io/apiserver/Godeps/Godeps.json
UU staging/src/k8s.io/cli-runtime/Godeps/Godeps.json
UU staging/src/k8s.io/client-go/Godeps/Godeps.json
UU staging/src/k8s.io/csi-api/Godeps/Godeps.json
UU staging/src/k8s.io/kube-aggregator/Godeps/Godeps.json
UU staging/src/k8s.io/metrics/Godeps/Godeps.json
UU staging/src/k8s.io/sample-apiserver/Godeps/Godeps.json
UU staging/src/k8s.io/sample-cli-plugin/Godeps/Godeps.json
UU staging/src/k8s.io/sample-controller/Godeps/Godeps.json
UU vendor/gopkg.in/yaml.v2/decode.go
UU vendor/gopkg.in/yaml.v2/encode.go
+++ Please resolve the conflicts in another window (and remember to 'git add / git am --continue')
+++ Proceed (anything but 'y' aborts the patch)? [y/n]
终端会暂停在冲突阶段，请注意此时需要重新打开另一个终端去解决冲突文件，待手动解决完所有冲突进行检查：
~/path/to/kubernetes-lts/src/github.com/kubernetes/kubernetes:: tag-v1.12.10 ±✚ >R> : git add .
~/path/to/kubernetes-lts/src/github.com/kubernetes/kubernetes:: tag-v1.12.10 ✚ >R> : git am --continue
Applying: Limit YAML/JSON decode size
~/path/to/kubernetes-lts/src/github.com/kubernetes/kubernetes:: tag-v1.12.10 : git status
On branch tag-v1.12.10
nothing to commit, working tree clean
最重要的一步操作就是返回之前的终端，确认冲突已经完成，此时会去更新 patches/CVE-2019-11253.1.12.patch。
- 以上操作就是更新一个版本的 patch 整个操作，可以选择先提交到仓库跑 CI 的测试，如果当前版本的测试用例都通过了就说明此次修复有效。然后选择在此 patch 上向下兼容。修改
release.yaml文件:
- name: v1.12.10-lts.1
base_release: v1.12.10-ci
must: true
patches:
- CVE-2019-11253.1.12
- name: v1.11.10-lts.1
base_release: v1.11.10-ci
must: true
patches:
- CVE-2019-11253.1.11
# CVSS Score 5.0, < k8s1.13, https://www.cvedetails.com/cve/CVE-2019-11253/
# TODO
- name: CVE-2019-11253
patch:
- https://github.com/kubernetes/kubernetes/pull/83436.patch
- name: CVE-2019-11253.1.12
patch:
- patches/CVE-2019-11253.1.12.patch
- name: CVE-2019-11253.1.11
patch:
- patches/CVE-2019-11253.1.11.patch
继续执行 make v1.11.10-lts.1，如果有冲突的话，重复以上动作修复。直到验证所最后一个版本（v1.10.13-lts.1）。
- 当所有的冲突解决完以后，并不意味代码将可以正常使用，必须通过 CI 的测试用例。目前 CI 只支持
main分支。如果在自己的仓库，请在 main 分支进行修改，确保完全无误的情况下再提交 PR 申请合入 klts 主分支。
在 github 查看测试情况：
查看提交的所有 job 信息，下面说明 1.15.12 版本测试将不通过：
查看报错信息详情，将错误解决完后重新提交，直到通过所有的测试。
8 - 开发指南
8.1 - 克隆
本页介绍如何将 Kubernetes master 分支克隆到本地。
克隆主分支
请尝试只克隆主分支，由于 repos 仓库作为 rpm 和 deb 的软件源，直接克隆全部会非常大。
可执行以下命令克隆主分支：
git clone --single-branch -b main https://github.com/klts-io/kubernetes-lts
8.2 - 依赖
本页介绍如何在不同的操作系统上安装依赖。
安装依赖
运行以下命令安装依赖：
brew install jq git python@3 # 安装 brew, 请看 https://brew.sh/
pip3 install yq
运行以下命令安装依赖：
yum install -y epel-release
yum install -y jq git python3
pip3 install yq
运行以下命令安装依赖：
apt-get install -y jq git python3 python3-pip
pip3 install yq