Kubernetes集群的安全问题里，CVE漏洞是最让人头疼的一类。kube-apiserver、kubelet、containerd这些核心组件每隔一段时间就会爆出高危漏洞，比如早些年的CVE-2018-1002105（API Server提权漏洞）到近年的CVE-2023-5528（Windows节点提权）、CVE-2025-1097（Ingress-NGINX RCE），每一次都让运维团队紧张一阵。修复漏洞本身不难，难的是在不停机或者少停机的前提下完成修复，并且保证修复过程本身不引入新的问题。这篇文章把漏洞排查、修复方式选择、补丁管理流程三个环节拆开来讲，给出可以直接落地的方案。
第一步：搞清楚集群里到底有哪些CVE
修复之前必须先摸清家底。很多人一看到安全新闻就急着升级，结果升级完发现自己环境根本不受影响，白白折腾了一轮。排查要从两个维度入手：一是集群组件的版本信息，二是这些版本对应的已知漏洞列表。
获取组件版本最直接的方式是命令行。用kubectl version查看控制面版本，用kubectl get nodes -o wide查看各节点的kubelet版本。如果用的是托管集群比如EKS、GKE、AKS，还要注意托管组件和自建组件的版本可能不一致，比如节点上的kubelet版本经常落后于控制面。下面是一段收集版本信息的脚本：
#!/bin/bash
# 收集集群各组件版本信息
echo "=== 控制面版本 ==="
kubectl version --short 2>/dev/null || kubectl version
echo "=== 节点与kubelet版本 ==="
kubectl get nodes -o custom-columns=NAME:.metadata.name,VERSION:.status.nodeInfo.kubeletVersion,CONTAINER_RUNTIME:.status.nodeInfo.containerRuntimeVersion
echo "=== 关键插件版本 ==="
kubectl get deployment -n kube-system ingress-nginx-controller -o jsonpath='{.spec.template.spec.containers[0].image}' 2>/dev/null
拿到版本号之后，下一步是比对CVE数据库。人工查官网效率太低，推荐用自动化扫描工具。Trivy是目前用得最多的一个，它可以直接扫描集群配置和组件版本：
# 安装trivy kubernetes插件 trivy kubernetes --report summary cluster # 只看高危和严重级别 trivy kubernetes --severity HIGH,CRITICAL --report summary cluster # 扫描单个节点上的kubelet trivy kubernetes node worker-node-01
除了Trivy，还有kube-bench可以检查CIS基准合规性，美国的NVD和GitHub上的kubernetes/security公告页面是漏洞信息的第一手来源。建议把扫描动作纳入日常巡检，而不是等漏洞爆发了才临时查一次。
三种修复方式怎么选
拿到漏洞清单后，不是每个CVE都需要立刻处理。修复方式大致分三类：版本升级、热修复、缓解措施。选哪种取决于漏洞的可利用条件、影响范围和业务容忍度。
版本升级是最彻底的方式。Kubernetes的漏洞修复只进入最新的补丁版本，比如你用的是1.28.2，官方在1.28.4修复了某个漏洞，那么升级到1.28.4就能彻底解决。补丁版本（第三位数字）升级风险相对可控，API兼容性有保证，建议始终跟进。升级前务必看一遍官方的版本变更说明，并确认集群里的Admission插件、CRD、存储驱动都兼容目标版本。
# kubeadm集群升级示例：先升控制面第一个节点 # 1. 升级kubeadm apt-mark unhold kubeadm apt-get update && apt-get install -y kubeadm=1.28.4-1.1 apt-mark hold kubeadm # 2. 执行升级计划检查 kubeadm upgrade plan # 3. 应用升级 kubeadm upgrade apply v1.28.4 # 4. 升级kubelet和kubectl apt-mark unhold kubelet kubectl apt-get install -y kubelet=1.28.4-1.1 kubectl=1.28.4-1.1 apt-mark hold kubelet kubectl systemctl restart kubelet
热修复适用于不能立即升级的场景。托管集群用户可以通过修改节点池镜像或者触发节点替换来滚动更新kubelet；自建集群如果有Patcher能力，也可以只替换受影响的二进制。这种方式的好处是粒度小，缺点是容易造成版本漂移，后续升级时环境不一致的坑要提前想好。
缓解措施是临时止损手段。比如CVE-2018-1002105利用的是API Server的代理连接缺陷，如果一时无法升级，可以通过收紧RBAC权限、关闭不必要的代理访问、在网络层限制API Server的入站来源来降低被利用概率。缓解措施必须登记在案，标注有效期限，一旦正式修复方案就绪就立即替换掉，否则时间一长没人记得这些临时规则，反而成为安全死角。
建立可持续的补丁管理流程
单次修复靠人力可以扛过去，但漏洞会不断出现，靠人盯是不长久的。一个成熟的补丁管理流程至少包含版本跟踪、灰度升级、回滚预案三个环节。
版本跟踪方面，建议订阅kubernetes-security-announce邮件列表，同时用CI流水线定期执行Trivy扫描，把结果推送到告警系统。可以写一个定时任务，每周对比一次当前集群版本与官方最新补丁版本，超过两个补丁版本的差距就触发提醒：
apiVersion: batch/v1
kind: CronJob
metadata:
name: cluster-cve-scan
namespace: security-tools
spec:
schedule: "0 3 * * 1" # 每周一凌晨3点执行
jobTemplate:
spec:
template:
spec:
serviceAccountName: trivy-scanner
containers:
- name: trivy
image: aquasec/trivy:latest
args:
- kubernetes
- --severity
- HIGH,CRITICAL
- --report
- summary
- --exit-code
- "1"
- cluster
restartPolicy: OnFailure
灰度升级是控制风险的关键。节点升级要分批进行，先升测试环境，再升生产环境的非关键节点池，确认业务指标正常后再推进剩余节点。每个节点升级后要留出观察窗口，检查Pod调度是否正常、容器运行时是否稳定。对于控制面升级，多master集群要逐台执行，确认一台健康后再动下一台。PodDisruptionBudget要提前配置好，防止升级过程中可用副本数跌破底线：
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: web-pdb
namespace: production
spec:
minAvailable: 2
selector:
matchLabels:
app: web
回滚预案经常被忽视，但它是升级敢往前走的底气。升级前用kubeadm upgrade时记录好etcd快照，节点镜像回退脚本提前准备好并演练过。一旦升级后出现异常，比如CNI插件不兼容、存储挂载失败，能在一小时内回退到原状态。托管集群则要利用好版本保留策略，确认云厂商支持回退到上一补丁版本。
最后强调一点心态问题：不要追求零漏洞。生产集群里中低危漏洞常年存在，合理的做法是根据漏洞的CVSS评分、可利用条件和资产暴露面做风险排序，高危且可直接远程利用的优先处理，其余的排入正常迭代节奏。安全是风险管理，不是完美主义，把有限的精力花在最可能被利用的漏洞上，才是务实的补丁管理。
KubernetesCVE漏洞修复补丁管理修改时间：2026-09-06 00:46:49