GKEのCA失効対応はノード更新だけでは終わらない｜コンテナとWebhookの確認

Google Cloudは2026年10月23日、eMudhra（emSign）の認証局（CA）の秘密鍵問題についてGCP-2026-071を公開しました。GKEを使うWebサービスでは、自動更新を待つだけでよいか、アプリ用コンテナも作り直す必要があるかを確認してください。ノードを更新しても、コンテナ内の信頼ストアは別に残ります。

本稿は10月24日10時10分（日本時間）に確認した告知に基づく続報です。新しい情報はGoogle CloudとGKEでの対応範囲・修正版・利用者の作業です。CAの問題そのものを、この日に初めて発覚した事件として扱うものではありません。出典：Google Cloud：GCP-2026-071の全体告知。

今回追加された対応判断

本サイトでは、10月20日の確認内容を基にFirefoxのOneCRLとeMudhraの証明書対策を扱いました。ブラウザーに届く遮断情報と、サーバーで動く処理の信頼情報は管理経路が異なります。今回はGKEの更新担当者とアプリのビルド担当者が、それぞれ作業を持つ点が読者の対応を変えます。

Googleの全体告知は、10月17日に8件の下位CA証明書に関係する秘密鍵侵害の報告を受けたと説明しています。Google Cloud基盤は侵害されておらず、同社のテレメトリーではGoogle Cloudワークロードへの悪用の証拠はないとしています。これは提供元による観測の説明であり、世界中で悪用がないという確認ではありません。

問題となるのは、影響するCAを信頼したまま外部TLS接続を行うクライアントです。攻撃者が通信経路へ介入できる条件では、偽の証明書によるなりすましが問題になります。自社サイトの証明書の発行元を確認するだけで、バックエンドから外部APIへ接続する処理まで対象外と判断しないでください。

GKE内部の通信と外部接続を分ける

GKEの告知はCVE-2026-111943を掲載し、深刻度をHighとしています。COSまたはUbuntuノードイメージを使う、現在サポート中のStandardとAutopilotを対象としています。クラスター内部のコントロールプレーンとノード間のmTLSは独立したプライベートPKIを使うため影響しません。一方、外部レジストリーからのイメージ取得や外部HTTPS Webhookへの接続は確認が必要です。出典：Google Cloud：GKEのGCP-2026-071と修正版。

運用上は、外部へ出る通信を担当単位で整理すると取りこぼしを減らせます。以下は本サイトの点検案です。接続先の一覧を作ることと、実際にどの信頼ストアを参照するかを調べることを、同じ作業として終わらせないようにします。

管理対象	担当者が確認すること
GKEクラスターとノードプール	モード・ノードOS・実行中の版・更新先
Webアプリとバッチのイメージ	ベースイメージ・CAパッケージ・同梱ランタイム
外部Admission Webhook	接続先・caBundle・証明書の更新担当
開発端末とCIのGoogle Cloud CLI	インストール元・更新経路・実行中の版

COSは修正版を確認して手動更新を検討

Googleはノード自動アップグレードが有効でも、クラスターとCOSノードプールの手動更新を推奨しています。告知に掲載された修正版は次のとおりです。これはCOS向けの表であり、Ubuntuノードの修正完了を意味しません。

GKE系列	COS向け修正版（同系列のこの版以降）
1.36	1.36.5-gke.1817000
1.35	1.35.9-gke.1390000
1.34	1.34.12-gke.1508000
1.33	1.33.13-gke.2152000
1.32	1.32.13-gke.2883000
1.31	1.31.14-gke.3093000

確認時点では、GKE告知のUbuntu向け修正版は今後追記する扱いです。Ubuntu側のCAパッケージに修正があることと、GKEが配布するUbuntuノードイメージの修正版が案内されたことを区別します。未掲載のGKE版を推測して更新先に指定しないでください。

手動更新の手順はGoogle Cloud：GKEクラスターの手動アップグレードで確認できます。Standardではコントロールプレーンとノードプールを別々に管理します。Autopilotでは利用者が手動更新する対象が異なるため、Standardの操作をそのまま当てはめないでください。

本サイトの推奨順序は、現在の構成を記録し、利用できる修正版を確認し、通常の変更管理に沿って更新し、完了後に実行中の版を再確認することです。ノードの入れ替えを伴う作業では、レプリカ数、終了処理、Podの退避、接続の再試行を事前に確認します。管理画面で更新を開始できたことだけを完了の記録にはしません。

アプリ用コンテナは再ビルドと再デプロイが必要

GKEの告知は、アプリ用コンテナがホストノードのルートCAストアを引き継がないことを明記しています。ノード更新と並行して、修正済みベースイメージからアプリ用イメージを再ビルドし、再デプロイする必要があります。古いイメージを同じノードへ再配置するだけでは、この作業の代わりになりません。

Dockerの公式文書は、イメージが作成時点のスナップショットであることと、定期的な再ビルドを説明しています。--pullは新しいベースイメージの確認に、--no-cacheはビルドキャッシュを使わない処理に関係します。キャッシュを無効にするだけでは、ベースイメージの更新まで保証しません。出典：Docker：イメージ再ビルドとキャッシュのベストプラクティス。

次はタグでベースイメージを参照する場合のビルド例です。本記事では実環境で実行・測定していません。利用中のDockerfileとレジストリー、依存関係の固定方法に合わせて検証してください。

docker build --pull --no-cache -t webapp:ca-refresh .

FROMをダイジェストで固定している場合は、承認した修正版のダイジェストへ更新する工程が先に必要です。同じ古いダイジェストのまま再ビルドしても、新しい内容へ自動的に置き換わるとは考えないでください。固定は再現性に役立ちますが、修正版を選び直す責任も伴います。

本サイトの実装案では、ビルド記録にベースイメージのダイジェスト、CA関連パッケージの版、アプリのリビジョン、成果物のダイジェストを残します。配備後は、その成果物が実際のPodで動くことを確認します。CIのビルド成功、レジストリーへの登録、本番の切り替えを別々の完了条件にすると、作り直しただけで止まる事故を防ぎやすくなります。

UbuntuとJavaの信頼ストアも確認する

Canonicalの告知は10月20日公開、22日にlibnss3とJavaの情報を追記しています。Ubuntuではca-certificatesとlibnss3の更新を案内し、Java利用環境には信頼ストアの同期に追加の手動対応が必要と説明しています。出典：Canonical：eMudhraのCA侵害へのUbuntuの対応。

独自に追加したCAがJavaのストアだけに入っている場合、再生成後に追加し直す必要があります。公式手順を適用する前に、追加CAの所在、復元方法、対象プロセスを記録してください。CAストアの削除・再生成を、利用状況の分からない全コンテナへ一律実行する手順にはしません。

点検は実際に稼働するランタイムを起点に行います。仮に、OSのCAパッケージを更新済みでも、アプリが独自の証明書バンドルを同梱していれば、確認先はその同梱物へ移ります。これは構成を考えるための仮想例であり、特定のアプリ製品で未修正を確認したという意味ではありません。

外部WebhookのcaBundleを点検する

Kubernetesの公式文書では、WebhookのclientConfigで接続先とCAバンドルを設定します。caBundleを指定しない外部URLの例はシステムの信頼ルートを使います。明示する場合は、接続先のサーバー証明書を検証できる正しいCAバンドルが必要です。出典：Kubernetes：Admission WebhookのTLSとCAバンドル。

次の読み取りコマンドは、設定を調査する入口の例です。実行権限と接続先クラスターを確認し、取得したYAMLの各Webhookについて、外部URLか、caBundleが設定されているか、誰が証明書更新を管理するかを照合します。本記事ではコマンドの実行検証は行っていません。

kubectl get validatingwebhookconfigurations,mutatingwebhookconfigurations -o yaml

空欄を見つけたら、無関係なCAを入れて埋めるのではなく、接続先の運用者と信頼の範囲を決めます。明示したバンドルも、証明書の更新時に追随できることが必要です。また、証明書エラーを消す目的でWebhookの失敗時ポリシーを緩める操作は、Admission制御の判断を変えるため、今回のCA更新とは分けて審査してください。

更新後に何をもって完了とするか

以下は提供元の合否判定そのものではなく、本サイトが提案する作業の完了条件です。通常のHTTPS接続が成功しても、侵害されたCAを拒否できる証明にはなりません。正常性の確認と、適切な修正版・信頼設定を使うことの確認を組み合わせます。

作業	残す証拠
GKE更新	コントロールプレーンと各ノードプールの実行中の版
イメージ更新	修正済みベースと配備済み成果物のダイジェスト
ランタイム確認	実際に参照するCAストアと更新記録
業務確認	外部API・イメージ取得・Webhookの正常性とエラー
継続確認	Ubuntuノード等の未完了項目と次の確認担当

接続障害が起きた場合は、対象ホスト名、証明書チェーン、プロキシ、参照するストアを調べます。信頼を取り消したCAを戻したり、TLS検証を無効にしたりして復旧扱いにすると、更新の目的を失う可能性があります。ロールバック候補にも修正済みの依存関係を含める計画を持ってください。

Google Cloud CLIも全体告知の更新対象です。開発端末だけでなく、CIの実行環境で固定したCLIやイメージを確認します。マネージドサービスの基盤対応と、自社が管理するOS・コンテナ・クライアントの更新は同じ進捗にはなりません。自社の責任範囲を分けて記録することが、今回の対応の要点です。

これは公開情報の定期確認に基づく記事であり、常時監視や自社環境での侵入調査を実施した結果ではありません。修正版やサービス別案内は更新され得るため、実作業の直前にも公式告知を再確認してください。