Istio 1.29.7 发布：安全修复之外，升级还要关注 CNI、JWKS 与 XDS 鉴权

2026-08-27 29 预计阅读时间: 1 分钟
来源: istio.io AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

Istio 1.29.7 是一次以安全修复为核心的补丁版本，主要针对 Envoy、istiod、istio-cni、Gateway API 和 ambient mode 做了加固与稳定性修复。对于运行生产集群的团队，这次升级不应只理解为替换镜像，还需要同步检查节点 nftables、Webhook 就绪状态、JWKS 拉取策略以及 XDS 访问控制。

这次版本修复了什么

Envoy 漏洞集中修复

1.29.7 更新了 Envoy，修复了多项 CVE，覆盖 HTTP/2、HTTP/3、QUIC、CONNECT、ext_authz、RBAC、URL 路径匹配和通用 HTTP Upgrade 等代码路径。其中多项漏洞 CVSS 评分为 7.5，典型问题包括：

  • HTTP/2 trailers、重复 Host header 和 QUIC datagram 处理中的内存安全问题。
  • safe_regex 在非 UTF-8 header 字节上的 RBAC 负匹配失败开放问题。
  • ext_authz 处理特殊 CONNECT 请求时的异常终止和 use-after-free。
  • HTTP/3 IPv6 地址、ALPN 连接池选择以及路径参数规范化问题。
  • 通用 HTTP Upgrade 场景中的跨用户响应污染。
  • 使用 ignore_path_parameters_in_path_matching 时可能出现的 RBAC 绕过。
  • Envoy HTML stats 接口中的存储型 XSS。

这些漏洞并不意味着所有 Istio 部署都会受到同样影响，但只要集群暴露了对应协议或功能，就应把补丁升级纳入安全处置流程。

Istio 控制面和数据面安全加固

本版本还修复了一个 BackendTLSPolicy 在 CA 引用无法解析时降级为明文的 fail-open 问题。istiod 的 JWKS 获取逻辑新增了 SSRF 防护：默认阻止链路本地地址和已知云元数据地址，并要求响应内容是有效 JWKS。私有地址和 loopback 地址仍然可以访问，但可以通过 BLOCKED_CIDRS_IN_JWKS_URIS 进一步限制。

XDS API generator 现在默认要求经过验证的控制面身份。此前，只要能够访问 Istiod XDS 端口，客户端就可能读取跨命名空间的 Istio 配置。相关开关默认值为：

ENABLE_XDS_API_GENERATOR_AUTH: "true"

只有在存在明确兼容性需求时，才应考虑设置为 false，并同时限制 XDS 端口的网络可达范围。

Istio 还统一转义了若干 sidecar 注解，包括 proxyImage、bootstrapOverride、logLevel、componentLogLevel 和 agentLogLevel，避免恶意注解值被插入 sidecar 或 gateway 注入模板生成的 Pod、Deployment 字段。

升级时必须检查的运行环境

节点 nftables 版本

Istio distroless 镜像升级了 nftables 版本，并移除了此前固定为 1.1.1 的版本锁定。这个锁定曾用于规避旧版 Kubernetes 节点 nftables 与镜像内较新版本之间可能导致的崩溃问题。现在主要 Linux 发行版已经发布修复，因此升级前应把节点上的 nftables 更新到发行版可用的最新版本。

可以在节点或节点镜像构建流程中确认版本：

nft --version

# Debian/Ubuntu 示例
sudo apt-get update
sudo apt-get install --only-upgrade nftables

# RHEL/Fedora 示例
sudo dnf upgrade nftables

实际命令应按节点操作系统和企业软件源调整。若升级后仍观察到 nftables 崩溃，应记录节点 OS、内核、nftables 和 Istio 版本，必要时暂时回退到较旧的 Istio 版本，并推动节点操作系统供应方提供修复。

istiod Webhook 就绪竞态

1.29.7 修复了 istiod 启动期间的一个竞态：readiness probe 可能先报告就绪，但专用注入与校验 Webhook 服务的 --httpsAddr，默认 :15017，尚未开始监听。这样会导致刚检测到 istiod Ready 后立即创建资源时，间歇性出现 webhook timeout。

升级后可以这样验证：

kubectl -n istio-system rollout status deployment/istiod --timeout=5m
kubectl -n istio-system get pods -l app=istiod -o wide
kubectl -n istio-system logs deployment/istiod --since=10m | rg '15017|webhook|ready'

该问题不影响 Webhook 与主 HTTP 服务共用、且 --httpsAddr 为空的部署。即便如此，生产升级仍应在控制面 Ready 后等待一小段时间，并通过实际创建测试资源验证 MutatingWebhookConfiguration 和 ValidatingWebhookConfiguration。

ambient、CNI 与多集群修复

本版本对 ambient mode 的边界条件进行了多项修复：

  • ingress gateway 在远端工作负载位于不同网络时，不再绕过 waypoint proxy，授权策略可以正常执行。
  • istio-cni 不再把 hostNetwork Pod 误认为适合 ambient 纳管的对象。
  • CNI 节点代理修复了 procfs 扫描中的文件描述符泄漏。
  • CNI 在扫描过程中发现多个网络命名空间时，会验证命名空间是否持有该 Pod 的 IP，避免把 Pod 错配到其他 Pod 的网络命名空间和身份。
  • ambient 多集群场景下，远端集群删除或更新造成的 istiod goroutine 和内存泄漏得到修复。
  • ztunnel 重连不再总是触发完整 WDS 推送。新版会为 WDS 资源分配基于内容的版本，客户端通过 initial_resource_versions 报告已有版本后，istiod 只重新发送断连期间发生变化的资源。

旧版 ztunnel 如果不报告资源版本，仍会接收完整资源集。因此，升级控制面后应结合 ztunnel 版本、集群数量和 WDS 推送大小观察 istiod CPU、内存及配置下发延迟。

其他值得关注的修复

1.29.7 还修复了以下问题：

  • istiod 选主每次重新获得领导权时泄漏一个 goroutine。
  • AuthorizationPolicy 数量增加时 istiod CPU 使用率异常增长。
  • Gateway listener 名称清洗后产生相同 Service 端口名，导致 Gateway 端口无法发布的问题。
  • Gateway API 跨命名空间 TLS 引用在检查 ReferenceGrant 之前泄露 Secret 或 ConfigMap 是否存在的信息。
  • Gateway proxy Deployment 在 istiod 启动阶段可能永久创建失败。
  • MCP 配置服务的 XDS API generator 未验证控制面身份的问题。
  • 指定工作负载获取 PeerAuthentication 时的性能问题。

一份可执行的升级检查清单

下面的命令假设 Istio 使用 istioctl 安装器，具体版本和发布渠道请按组织环境替换：

set -euo pipefail

ISTIO_VERSION=1.29.7
istioctl version
kubectl version --short 2>/dev/null || kubectl version

# 升级前检查节点上的 nftables
kubectl get nodes -o name
nft --version || true

# 预览并执行 Istio 升级
istioctl upgrade --set revision=${ISTIO_VERSION} --dry-run
istioctl upgrade --set revision=${ISTIO_VERSION}

# 检查控制面、网关和 CNI
kubectl -n istio-system rollout status deployment/istiod --timeout=5m
kubectl -n istio-system get pods
kubectl get mutatingwebhookconfiguration,validatingwebhookconfiguration | rg 'istio|ambient'

# 运行安装和代理配置检查
istioctl verify-install
istioctl analyze --all-namespaces

istioctl upgrade 的参数会因安装方式、revision 模式和 IstioOperator 配置而不同。执行生产升级前，应在测试集群验证自定义 EnvoyFilter、Gateway API、ambient CNI 和外部 JWKS 访问；尤其要审查 EnvoyFilter 中的 proxyVersion 正则表达式。1.29.7 将该匹配表达式限制为 1024 个字符，以避免正则编译消耗过多 istiod 内存和 CPU，但过长表达式仍可能暴露配置质量问题。

采用建议

如果集群使用 HTTP/2、HTTP/3、QUIC、ext_authz、RBAC 路径匹配、ambient mode 或 Gateway API，1.29.7 的安全修复与行为修复都具有较高相关性。升级时应把补丁版本、节点 nftables、Webhook 监听状态和 XDS 网络访问控制一起纳入变更单。

升级完成后，至少观察以下指标和日志：istiod CPU 与内存、Webhook timeout、CNI 纳管结果、ztunnel WDS 推送大小、Gateway 端口发布状态，以及 JWKS 拉取失败记录。对于无法立即升级的环境，应先降低 XDS、Istiod 管理端口和 Envoy stats 接口的网络暴露面，并安排尽快完成版本迁移。

# AI # Go # Istio # Kubernetes # LLM # Service Mesh # 云原生 # 前端 # 可观测性 # 后端 # 安全

相关推荐