Envoy Gateway 1.9.1 リリース：v1.9.0 の課題を解決

Envoy Gateway は、2026年8月28日に v1.9.1 をリリースしました。このアップデートは、主にセキュリティ強化、アップグレードの信頼性向上、および運用上の正確性の改善に焦点を当てています（InfoQ）。

最も注目すべき変更点は、Secret Discovery Service (SDS) および Route Discovery Service (RDS) の初期フェッチタイムアウトに関するものです。v1.9.0ではこのタイムアウトがゼロに設定されましたが、これにより、Kubernetesクラスターが欠落したSecretやエンドポイントを indefinitely 待機し続け、「warming」状態に留まるという問題が発覚しました。

これはCDS（Cluster Discovery Service）の更新を妨げ、ヘルスチェックの遅延を引き起こしていました。v1.9.1では、Envoyのデフォルトである15秒のタイムアウトが復元され、v1.8.xの動作に戻されています。

v1.9.1では、SDS/RDSの初期フェッチタイムアウトがEnvoyのデフォルトである15秒に復元され、v1.9.0で発生したサービス停止のリスクが低減されました。

v1.9.0 からのアップグレードパスに注意

この変更は、すでにv1.9.0を稼働させている組織にとって複雑な課題をもたらします。Envoy Gatewayは、コントローラーのアップグレード中にSDS設定を変更すると、新しいコントローラーがデプロイされている間も実行中のプロキシに影響を及ぼすEnvoyの問題を引き起こす可能性があると警告しています。

このシナリオでは、TLSリスナーが証明書なしでアクティブになり、新しいTLSハンドシェイクが失敗することがあります。バックエンドのTLS設定やグローバルなレート制限サービスでも同様の問題が発生する可能性があります（InfoQ）。

v1.8.xを使用しているユーザーには、v1.9.0をスキップしてv1.9.1へ直接アップグレードすることが推奨されています。既存のv1.9.0デプロイメントにはより慎重な対応が必要です。

Envoy Gatewayは、プロキシPodを迅速に置き換えるローリングアップデート設定を推奨していますが、これには十分なクラスタ容量が必要であり、Podの置き換え中に既存の接続が中断される可能性があります。特に、長期間維持されるWebSocketやgRPC接続は、置き換え中に中断される可能性があるとリリースノートで明確に警告されています。

アップグレード元のバージョン 推奨されるアップグレード経路 注意点
v1.8.x v1.9.1 へ直接アップグレード v1.9.0 の問題の影響を受けないため、比較的安全にアップグレード可能。
v1.9.0 ローリングアップデート コントローラーアップグレード中のSDS設定変更でTLSハンドシェイク失敗のリスクあり。十分なクラスタ容量が必要。長期間のWebSocket/gRPC接続が中断される可能性あり。迅速なプロキシPodの置き換えが推奨されるが、計画的な停止時間や接続中断の考慮が必要。

セキュリティの強化とWasmイメージの安全性向上

v1.9.1リリースにおけるもう一つの大きなテーマはセキュリティです。Envoy Gatewayは、OAuth2/OIDCセッションCookieの暗号化にAES-256-GCMを有効化し、レガシーなAES-256-CBC復号化パスのサポートを削除しました。

これは、CVE-2026-47775として特定されたパディングオラクル脆弱性に対処するためです。アップグレード後、古い暗号化メカニズムを使用していた既存のセッションは、ユーザーが再度認証を行う必要があります（InfoQ）。

さらに、いくつかのセキュリティ境界が強化されています。OIDC発行者URLには追加の検証が適用され、OCI WasmイメージのプルにおいてHTTPSからHTTPへのサイレントなフォールバックが廃止されました。これはサプライチェーンセキュリティにとって特に重要です。

以前は、HTTPSリクエストを拒否するOCIレジストリがEnvoy GatewayをプレーンHTTPにフォールバックさせ、経路上の攻撃者が任意のWasmコードを提供する可能性がありました。v1.9.1では、この暗黙的なフォールバックが削除され、HTTPはレジストリが明示的に「非セキュア」として構成されている場合にのみ許可されます。

エンジニア目線で見ると：移行コストは小さいが検証は必須

v1.9.1のリリースは、特にv1.9.0のユーザーにとって重要なアップデートだと感じます。SDS/RDSのタイムアウト問題は、一見すると些細な変更に見えますが、本番環境での長期的なサービス安定性には極めて大きな影響を及ぼします。GitHubのIssueで報告されたアウトテージ事例は、TLS証明書が失われHTTPSトラフィックが停止するという深刻なもので、手動でのプロキシ再起動が必要だったとのこと。

これは、我々が本番環境で運用する上で最も避けたい事態の一つです。このようなトラブルを防ぐためにも、v1.9.0からの移行は十分な検証計画が不可欠ではないでしょうか。

セキュリティ強化に関しては、OAuth2/OIDCのAES-256-GCMへの移行は歓迎すべき変更です。古い暗号方式の脆弱性に対処し、より堅牢なセキュリティを提供してくれるのは、サービス提供者として安心できます。個人的には、WasmイメージのプルにおけるHTTPSからHTTPへの暗黙的なフォールバックの廃止は、サプライチェーン攻撃のリスクを大幅に低減する点で非常に評価できます。

自分の個人プロダクトでもWasmを使った機能拡張を考えているので、こうした基盤のセキュリティ強化は、安心して新しい技術を採用するための大きな後押しになると感じます。GCP環境でEnvoy Gatewayを運用している場合、Cloud LoggingやCloud Monitoringとの連携で、アップグレード中のプロキシの状態変化をより詳細に監視する必要があると考えます。アップグレード前のスナップショットやロールバック計画も忘れずに準備したいところです。