Envoy Gateway 1.9.1 Tightens Security and Addresses a Difficult Upgrade Path

Envoy Gateway 1.9.1 加强安全防护并解决升级难题 - InfoQ

InfoQ 首页 News Envoy Gateway 1.9.1 加强安全防护并解决升级难题

DevOps

QCon AI 波士顿（2027年7月8-9日）：AI原型已经成功。生产环境会发生什么？

Envoy Gateway 1.9.1 加强安全防护并解决升级难题

2026年10月2日 4分钟阅读

作者

• Craig Risi

#### 关注我们

YouTube

232K 粉丝

LinkedIn

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 赞

Bluesky

收听本文 -

0:00

音频准备就绪

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

• 阅读列表

Envoy Gateway 已发布 v1.9.1 版本，这是一个维护版本，重点加强安全防护、升级可靠性和操作正确性，继更广泛的 v1.9 版本发布之后。该更新于8月28日发布，撤销了 v1.9.0 版本中关于机密和端点获取的更改，修复了多个安全问题，并为 Gateway API 和 xDS 转换引入了更精细的可观测性。

最重要的更改涉及 Secret Discovery Service（SDS）和 Route Discovery Service（RDS）的初始获取超时设置。Envoy Gateway 1.9.0 版本将此超时设置为零，但项目发现，如果集群无限期等待缺失的机密或端点，可能会停留在预热状态，阻碍 CDS 更新并延迟健康检查。1.9.1 版本恢复了 Envoy 默认的 15 秒超时，使此行为回归到 v1.8.x 的模式。

对于已经运行 v1.9.0 的组织来说，这一更改更为复杂。Envoy Gateway 警告称，在控制器升级期间更改 SDS 配置可能会触发影响代理的 Envoy 问题，这些代理在新控制器部署期间仍处于运行状态。在受影响的场景中，TLS 监听器可能在没有证书的情况下激活，导致新的 TLS 握手失败。后端 TLS 配置和全局限速服务可能会遇到类似的证书或 CA 问题。

对于使用 v1.8.x 的用户，项目建议直接升级到 v1.9.1 并跳过 v1.9.0。现有 v1.9.0 部署需要更多谨慎：Envoy Gateway 建议使用快速替换代理 Pod 的滚动更新配置，但这需要足够的集群容量，并可能在替换 Pod 时终止现有连接。发布说明特别警告称，长时间运行的 WebSocket 和 gRPC 连接可能在替换过程中被中断。

一位在生产环境中运行 Envoy Gateway 的用户在 GitHub 上提交的问题描述了一次故障，其中长期运行的 Envoy 代理丢失了下游 TLS 证书并停止提供 HTTPS 服务，恢复需要手动重启代理。该问题将此行为与新 SDS 订阅的处理以及 v1.9.0 中引入的初始获取超时更改联系起来。

安全防护是此次发布的另一个重要主题。Envoy Gateway 现在为 OAuth2/OIDC 会话 cookie 加密启用了 AES-256-GCM，并移除了对旧版 AES-256-CBC 解密路径的支持，解决了被标记为 CVE-2026-47775 的填充 oracle 漏洞。使用旧加密机制的现有会话在升级后需要用户重新认证。使用替换 Envoy 引导的部署需要显式配置相应的运行时设置。

该版本还加强了其他多个安全边界。OIDC 发行者 URL 现在会接受额外验证，OCI Wasm 镜像拉取操作不再静默地从 HTTPS 回退到 HTTP，同时修复了一个涉及租户提供的 EnvoyProxy 配置的安全上下文问题。后者阻止了租户提供的 Kubernetes 安全上下文完全替换 Envoy Gateway 的强化默认值，否则可能导致特权执行或以 root 身份运行等限制被移除。

Wasm 相关的改进对供应链安全尤为重要。此前，如果 OCI 仓库拒绝 HTTPS 请求，可能导致 Envoy Gateway 回退到明文 HTTP，从而让路径上的攻击者注入任意 Wasm 代码。1.9.1 版本移除了这种隐式回退机制；现在只有在仓库明确配置为不安全时才允许使用 HTTP。

多个修复改进了控制器和流量管理行为中较为隐蔽但重要的部分。OIDC 流程的 Cookie 现在限定在重定向路径范围内，减少了废弃认证 Cookie 的无谓传播。命名空间标签变更现在会自动监控，使得路由接受状态可在不重启控制器的情况下重新评估。该版本还修复了主机名冲突处理、缺少可选 CRD 时的控制器崩溃问题，以及在 UDP 路由上配置一致性哈希时的错误行为。

该版本通过 EDS 使用 Kubernetes 服务和 EndpointSlice 信息，改进了全局速率限制集成。这使得在服务实例扩展时，请求仍能继续访问合适的速率限制服务副本，同时保留基于 DNS 的先前行为作为回退方案（当服务或端点无法被发现时）。

一个较为低调的改进可能对平台工程团队有帮助。Envoy Gateway 现在为 Gateway API 和 xDS 转换添加了按阶段划分的追踪跨度。操作人员现在可以识别处理时间在监听器处理、HTTP/gRPC 路由、策略处理、EnvoyPatchPolicy 处理、扩展钩子和 xDS 验证等各个阶段的分布情况，而不是将缓慢的转换视为单一的不透明操作。

因此，Envoy Gateway 1.9.1 的改进远不止是一系列常规修复。该版本体现了在大规模运行 Kubernetes 原生网关时的一些操作复杂性：配置变更可能影响正在运行的代理状态，安全边界延伸至 Wasm 和租户控制资源，控制平面性能日益需要独立的遥测支持。

对于正在评估或已部署 Envoy Gateway 的团队，升级路径至关重要。v1.8.x 用户可直接升级到 v1.9.1，而 v1.9.0 用户在升级前应特别注意文档中提到的代理替换策略和 TLS 影响。该版本本身以 v1.9.1 发布，项目文档提供了详细的升级和配置指南。

关于作者

作者信息

#### Craig Risi

显示更多

显示更少

#### 本内容属于 DevOps 主题

##### 相关主题：

• DevOps
• 应用安全
• 云安全
• Envoy
• 相关编辑内容
• 相关赞助商 [通过 O'Reilly 下载] 工程领域人工智能采纳扩展（Scaling AI Adoption in Engineering）

• 赞助商相关 发现测试遗漏的错误。Antithesis 使用确定性模拟探索数千种故障场景，在错误进入生产环境之前发现难以复现的错误。了解其工作原理

InfoQ 电子报

每周二发送上周 InfoQ 内容的汇总。加入超过 25 万名高级开发者的社区。查看示例

我们保护您的隐私。