Kubernetes 控制面与节点版本偏移安全评估：准入、运行时与网络插件行为核验

Kubernetes 集群升级期间，控制面、新旧节点、容器运行时和网络插件可能暂时处于不同版本。安全风险不只是组件能否启动：API 服务器可能接受了符合准入规则的 Pod，但节点上的运行时默认值、实际内核限制或网络策略执行结果并不相同。最终表现可能是策略对象和配置文件都在，部分工作负载却没有得到预期保护。

以下方法适用于能够查看控制面配置、节点状态和网络插件行为的自管或可控集群。验证应在授权范围内进行，优先使用隔离测试命名空间和无敏感数据的测试工作负载；生产流量测试、节点排空和回滚都需要纳入变更窗口。

升级前：建立可比较的安全基线

先把“版本偏移是否允许”和“安全行为是否一致”分开处理。前者应依据当前及目标版本的官方版本偏移策略、升级路径和插件兼容性文档判断；后者仍需在实际集群中验证。不要仅凭节点处于 Ready 状态认定升级安全，也不要假设任意跨版本组合都受支持。

盘点组件和工作负载

记录每个控制面实例、节点和相关插件的版本与配置。多 API 服务器集群还要确认各实例的启动参数、准入配置和加载的配置文件一致。

kubectl version
kubectl get nodes -o wide
kubectl get nodes \
  -o custom-columns=NAME:.metadata.name,KUBELET:.status.nodeInfo.kubeletVersion,RUNTIME:.status.nodeInfo.containerRuntimeVersion,OS:.status.nodeInfo.osImage
kubectl get pods -A -o wide
kubectl get daemonsets -A -o wide
kubectl get runtimeclass
kubectl get networkpolicy -A
kubectl get namespace --show-labels

节点上还应通过现有配置管理系统或经授权的主机访问，核对 kubelet、容器运行时、CNI 配置和插件二进制文件的实际版本及生效配置。DaemonSet 镜像版本只是线索：还要确认各节点上的插件 Pod 已就绪、配置已加载，并记录是否存在使用 hostNetwork、自定义 RuntimeClass 或特殊内核配置的工作负载。

为后续对比保存以下基线：

记录变更前的配置和恢复方式，但不要把包含凭据的配置文件直接写入工单或普通日志。

混合版本：验证准入控制一致性

Pod Security Admission 在 API 服务器侧实施 Pod Security Standards；节点版本不同，不意味着准入控制分别在每个节点上执行。因此，测试应覆盖不同 API 服务器的准入决策，再单独覆盖被接受的 Pod 在不同节点上的实际运行效果。

核对策略和豁免

检查目标命名空间的 pod-security.kubernetes.io/enforce、audit、warn 标签及各自的版本标签，同时核对 API 服务器准入配置中的默认设置与豁免项。未显式固定策略版本时，应特别关注控制面升级后策略解释可能发生的变化。固定版本可以降低意外变化，但也意味着不会自动采用较新规则，需要安排后续评估。

在隔离命名空间中准备两类最小测试清单：

• 预期允许：满足当前指定级别和版本要求的 Pod。
• 预期拒绝：只改变一个明确受限的字段，例如在适用的策略级别下请求特权容器。

通过服务端试运行检查准入结果，避免实际创建不安全测试 Pod：

kubectl apply --dry-run=server -f pod-expected-allow.yaml
kubectl apply --dry-run=server -f pod-expected-deny.yaml

记录请求身份、命名空间标签、清单、响应、告警和审计事件。若使用负载均衡访问多个 API 服务器，一次成功或失败不能证明每个实例一致；应通过经授权的逐实例访问方式分别验证，并确保使用相同身份、请求和参数。还需区分 PSA 决策与其他准入 Webhook 的拒绝，不能把所有拒绝都归因于 PSA。

服务端试运行只能验证支持该请求路径的准入行为，不能证明节点已执行安全限制。对于预期允许的测试 Pod，还应实际部署并在目标节点核验。Pod Security Standards 的具体字段要求应以所选版本对应的官方标准为准。

混合版本：核验容器运行时的实际效果

容器运行时配置不仅包括配置文件，也包括 kubelet 传递的设置、运行时默认值、节点内核能力和工作负载自身的 securityContext。相同 Pod 清单在不同节点上运行时，应比较最终结果，而不是只比较 YAML。

选择每个节点版本、操作系统与运行时组合中的代表节点；对于安全敏感节点池，应逐节点覆盖。使用受控的节点选择约束将相同测试 Pod 放到目标节点，并确认实际调度位置：

kubectl get pod -n security-test -o wide
kubectl get pod -n security-test TEST_POD -o yaml
kubectl describe pod -n security-test TEST_POD

重点检查：

1. 显式配置与默认配置：分别测试业务清单中显式设置的安全上下文，以及有意依赖节点默认值的受控样例。对比 seccomp、权限提升、linux capabilities、用户身份和只读根文件系统等适用项。
2. 节点侧生效配置：结合运行时支持的检查工具、kubelet 配置及节点内核信息，确认配置文件不仅存在，而且已被当前进程加载。
3. 容器内可观测状态：在授权测试容器内，检查进程身份、/proc/1/status 中可见的能力集和 seccomp 状态，并结合运行时检查结果解释；不要只凭单个字段推断完整防护效果。
4. 功能性负例：在隔离环境中设计本应被拒绝的最小操作，确认旧节点与新节点的结果一致，同时排除镜像、用户权限或文件系统差异造成的假阳性。

不同运行时和操作系统提供的检查方式不同。测试清单应注明镜像摘要、运行时类、节点、预期结果和实际结果；发现默认值不一致时，优先评估能否在工作负载中显式声明所需安全属性，再通过受控变更统一节点配置。

混合版本：验证网络策略的真实流量路径

创建 NetworkPolicy 对象并不等于网络策略已经生效：集群需要支持相应策略执行的网络实现，而具体覆盖范围还取决于插件、配置和流量路径。Kubernetes 网络插件文档可用于核对网络插件的基本要求；实际策略能力仍需结合所部署插件的文档和测试结果确认。

在隔离命名空间部署带明确标签的客户端和服务端，并为测试对象设置符合预期的入口、出口策略。先确认测试服务本身可用，再执行允许和拒绝两类测试。禁止直接在生产命名空间套用默认拒绝策略，除非已经评估 DNS、监控、健康检查和业务依赖。

对实际使用的协议和端口分别测试，并按需覆盖 DNS、Pod IP 和 Service 访问。入口与出口应分别构造用例；如果业务使用 IPv6、hostNetwork 或插件自定义策略，也应依据实际实现单独验证，不要把普通 Pod 网络测试结果外推到这些路径。

判断拒绝是否有效时，先确认服务端正在监听、路由和名称解析正常，再比较策略启用前后的连接结果及插件日志、指标或流量观测记录。连接超时本身不能证明被策略阻断；故障路由或服务未启动也可能产生相同现象。

分批升级：把验证设为放行条件

按已核验的升级顺序实施，先在预生产环境复现，再选择小规模节点池或少量节点作为首批。每批升级前确认容量、Pod 中断预算、关键业务冗余和节点排空影响；升级过程中持续观察：

• API 请求错误、准入拒绝与告警是否偏离基线；
• 节点和关键 DaemonSet 是否就绪，运行时及 CNI 是否报错；
• 测试 Pod 是否成功创建、调度，运行时安全属性是否符合预期；
• 网络允许与拒绝用例是否通过，业务连接、DNS 和健康检查是否正常；
• 安全代理、日志采集与监控是否仍覆盖已升级节点。

每批完成后，重新执行对应节点组合的准入、运行时和网络测试，并保存节点名称、组件版本、测试时间、请求身份、预期与实测结果。只有验证通过且观察期内没有不可接受的异常，才推进下一批；若出现安全控制缺失，应暂停扩批，而不是仅凭业务暂时可用继续升级。

回滚安排与复盘

回滚计划应在升级前演练，并按组件分别定义，不把“恢复旧版本”视为必然可行：

• 控制面：确认所用发行版或部署工具支持的恢复路径、配置备份和数据恢复要求。控制面降级可能受版本及存储数据兼容性限制，不能未经核验直接执行。
• 节点和运行时：准备可重新加入集群的旧版节点镜像或节点池，以及对应配置；必要时将工作负载迁回已验证节点。排空、重建和替换节点都要考虑容量与中断影响。
• 网络插件：备份配置并确认插件支持的回退顺序。回退可能中断网络或改变策略执行，应先验证与控制面、节点版本的兼容性。
• 安全策略：保留变更前的命名空间标签、准入配置和网络策略。恢复策略时要同步验证业务连通性与拒绝用例，避免为恢复业务而长期留下过宽规则。

建议预先约定暂停或回滚触发条件，例如预期拒绝的请求被接受、受限流量可达、关键节点缺少策略执行能力，或业务错误率超过变更阈值。事件结束后，对照基线说明差异来自版本、配置、默认值还是测试环境，并更新测试清单和下一轮升级门槛。这样，Kubernetes 版本偏移就不只是一次兼容性检查，而成为可复核的安全控制一致性验证。