Istio 1.30.4 是从 1.30.3 升级而来的安全修订版本。它集中修复了 Envoy 中多项 HTTP/2、HTTP/3、RBAC、ext_authz 与响应处理漏洞，同时补上 Istio 控制面、注入模板、JWKS 拉取和多集群同步中的安全与稳定性问题。对于运行公网入口、跨集群流量、Gateway API 或细粒度授权策略的团队，这不是适合长期搁置的补丁版本。
这次修复覆盖了哪些攻击面
Envoy 修复列表中有多项 CVSS 7.5 的问题，影响面集中在代理最常承载的协议与策略路径：
- HTTP/2 trailer、重复
Host请求头和通用 HTTP Upgrade 的处理，分别涉及 use-after-free、内存耗尽与跨用户响应投毒风险。 - QUIC/HTTP/3 的 HTTP datagram、IPv6 scoped 地址、ALPN 连接池选择，以及 URL/path 参数规范化与匹配行为。
safe_regex在非 UTF-8 请求头下的负向 RBAC 匹配、ignore_path_parameters_in_path_matching相关的 RBAC 绕过。ext_authz对缺少:path的 CONNECT 请求，以及 raw HTTP client 的异常处理。- HTML stats 接口中的存储型 XSS。
这些问题的共同点是：应用代码即使没有变动，只要流量经过 Envoy sidecar、ingress gateway 或 gateway proxy，就可能落在受影响的解析、匹配或转发链路中。因此，评估范围不能只看业务 Pod，还应包括入口网关、东西向网关和 ztunnel。
Istio 控制面修复比版本号更值得关注
1.30.4 还修复了一批直接影响安全边界的 Istio 问题。
BackendTLSPolicy 在 sidecar 代理上引用的 CA 无法解析时，曾可能失败开放为明文连接。对依赖 BackendTLSPolicy 强制后端 TLS 的环境，这意味着应在升级后重新验证：证书引用失效时，流量是否被明确拒绝，而不是悄然降级。
Istiod 的 XDS API generator 现在默认要求已验证的控制面身份，ENABLE_XDS_API_GENERATOR_AUTH=true。此前，只要客户端能连接 Istiod 的 XDS 端口，就可能读取跨命名空间 Istio 配置。若环境中仍有兼容性依赖，可以临时设置 ENABLE_XDS_API_GENERATOR_AUTH=false，但应将其视为待清理的例外，而不是长期配置。
本次也收紧了 RequestAuthentication.jwksUri 的 SSRF 防护：Istiod 默认在拨号层阻断 link-local 和已知云元数据地址，并拒绝非有效 JWKS 的响应。私网和 loopback 地址仍可访问；需要更严格出站边界的集群可通过 BLOCKED_CIDRS_IN_JWKS_URIS 增加封锁网段。
此外，若工作负载创建者可写入 sidecar.istio.io/* 注解，应注意本次修复了 proxyImage、bootstrapOverride、logLevel、componentLogLevel、agentLogLevel 等注解在注入模板中的未转义插值问题。升级前后都应继续按最小权限控制谁能创建或修改带注入标签的 Pod、Deployment 与网关资源。
多集群与 Ambient 环境的可靠性改进
这一版本并不只修安全漏洞，也处理了若干容易表现为“重启 Istiod 后暂时恢复”的控制面问题：
- 远程集群凭据轮换后，网络网关可能从跨网络路由中消失。
istio-remote-secret轮换可能清空远程集群服务的 endpoint shard，导致跨集群不可达。- ingress gateway 在远程工作负载位于不同网络时，可能绕过 waypoint，进而跳过授权策略。
- istio-cni node agent 在节点重启后可能因 kubeconfig 时序而无法启动；同时修复了 hostNetwork Pod 被误判为 ambient 可纳管的问题。
- ztunnel 重连不再必然触发完整 WDS 推送。支持
initial_resource_versions的 ztunnel 会只接收断连期间变化的资源。
如果集群同时启用了多网络、多集群和 ambient mode，升级验证应覆盖远程服务发现、跨网络访问、waypoint 授权和节点重启后的 CNI 恢复，而不能只检查单集群 HTTP 连通性。
可以这样执行一次受控升级
下面示例假定控制面安装在 istio-system，并且当前 istioctl 已替换为与 1.30.4 对应的二进制。执行前请将 ISTIO_VERSION、profile、revision 和自定义 values 文件替换成实际值；生产环境应先在预发布集群完成同样的流程。
export ISTIO_VERSION=1.30.4
export ISTIO_NAMESPACE=istio-system
# 记录升级前版本、控制面状态和代理同步情况。
istioctl version
kubectl -n "$ISTIO_NAMESPACE" get pods
istioctl proxy-status
# 先检查现有配置是否存在明显问题。
istioctl analyze --all-namespaces
# 使用团队已审查的安装参数升级控制面。
# 将 production-values.yaml 替换为实际维护的 values 文件。
istioctl upgrade \
--set profile=default \
-f production-values.yaml \
-y
# 等待控制面可用，并复查代理与配置分发状态。
kubectl -n "$ISTIO_NAMESPACE" rollout status deployment/istiod --timeout=5m
istioctl proxy-status
istioctl analyze --all-namespaces
控制面升级完成不等于全部数据面已经使用新 Envoy。可以这样滚动重启带 sidecar 的业务命名空间，使新建 Pod 获取更新后的代理镜像；应排除不应重启的命名空间，并结合业务发布窗口执行。
kubectl -n payments rollout restart deployment
kubectl -n payments rollout status deployment --timeout=10m
# 检查一个工作负载的实际代理版本。
istioctl proxy-status | grep payments
对于使用远程 JWKS 的服务，可以在 values 文件中明确设置额外阻断网段。下面是可改造的 Helm values 片段，网段应根据组织网络规划调整：
pilot:
env:
BLOCKED_CIDRS_IN_JWKS_URIS: "127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"
ENABLE_XDS_API_GENERATOR_AUTH: "true"
这个配置会影响 Istiod 获取 JWKS 的能力。若身份提供商位于私网地址，不能直接照搬上述网段；应先确认允许的 JWKS 域名、解析结果和实际出站路径，再实施限制。
升级后的检查清单
- 确认
istioctl version中控制面和业务代理均已达到预期版本。 - 检查
istioctl proxy-status，避免出现长期STALE或NOT SENT的配置状态。 - 对使用
AuthorizationPolicy、负向 header 匹配或路径参数匹配的服务执行回归测试。 - 对使用
BackendTLSPolicy的后端验证正常 TLS 连接，并模拟 CA 引用错误以确认失败行为。 - 在多集群环境轮换一套测试用 remote secret，检查远程 endpoint、网络网关和跨网络授权链路是否持续可用。
- 检查依赖远程
jwksUri的 JWT 鉴权流程，尤其是私网 IdP 或自建身份服务。
1.30.4 的风险重点不只是单个 CVE，而是代理协议栈与控制面信任边界同时得到修复。升级时应优先保护入口网关和高权限服务，再按业务窗口完成 sidecar、gateway proxy 与 ztunnel 的数据面滚动更新。