eMudhra CA侵害：Kubernetesノードへのパッチ適用だけでは不十分な理由

2026年10月、認証局であるeMudhraが、証明書署名用の秘密鍵8つを、ランダムな384ビットの値ではなく1バイトの数値（4、56、66、115、155、156、230、237）として生成していたことを、ある研究者が発見しました。そのため、公開されているCA証明書から、誰でも1秒未満で秘密鍵を復元できました。影響を受けるTLS署名鍵を復元した者は、自分が管理していないドメインの証明書を発行できます。さらに通信を傍受したり経路を変更したりできる攻撃者は、侵害された発行者をまだ信頼しているクライアントに対して、正規のサービスになりすますことができます。自社の証明書がeMudhraから発行されたものでなくても、接続は危険にさらされる可能性があります。クライアントが偽造された証明書を受け入れてしまうと、攻撃者はその接続で送信される認証情報やリクエストデータを受け取り、改ざんしたレスポンスを返すことができます。

主要なブラウザーには、影響を受ける証明書をブロックする更新が配信されましたが、その保護がKubernetesにも自動的に及ぶわけではありません。ノード、コンテナイメージ、アプリケーションランタイム、クラスター設定は、それぞれが信頼する証明書を提供したり、独自の検証ルールを適用したりします。どこを修正すべきかは、稼働中のコンポーネントが実際にどれを使用しているかによって決まります。

Kubernetesは信頼情報をどこに持っているのか

Kubernetesクラスターは、単一の共有トラストストアを使っているわけではありません。コンテナランタイムは通常ノードの証明書に依存し、アプリケーションはイメージ内に独自のバンドルを含んでいることがあり、言語ランタイムがさらに別のセットを提供することもあります。追加のCAバンドルをKubernetesの設定に保存し、ワークロードにマウントすることもできます。

これらのコピーは、それぞれ別々に更新されます。また、稼働中のプロセスは更新前に読み込んだ証明書を保持し続けることがあるため、ファイルを修正しても、アプリケーションの信頼判断が修正されるとは限りません。以降のセクションでは、各レイヤーで何を更新すべきか、そして再起動や再読み込みがいつ必要になるかを説明します。

影響があるのは、対象となるパブリックな発行者を信頼している接続です。クラスターやメッシュのプライベートCAだけを信頼するよう制限された接続は、このインシデントによって自動的に危険にさらされるわけではありません。

次の図は、一般的なイメージのプルとアプリケーション接続を比較したものです。アプリケーションは、TLS設定に応じて、図に示したソースのうち1つ以上を使用します。

ノードの信頼情報とワークロードの信頼情報は、別々の経路で更新されます。稼働中の各クライアントは、変更された証明書を読み込み直す必要があります。

1. ノード：コンテナランタイムとコントロールプレーン

Kubernetesがイメージをダウンロードするとき、kubeletはcontainerdやCRI-Oなどのコンテナランタイムにその取得を依頼します。ランタイムはレジストリに接続し、ノードが信頼するCAを使ってHTTPS証明書を検証します。containerdやCRI-Oに設定したレジストリ固有のCAは、そのプールを置き換えるのではなく、プールに追加されます。そのため、それらのレジストリにもノードのバンドルが引き続き適用されます。

その信頼設定が侵害された発行者をまだ受け入れている場合、ネットワーク経路上の攻撃者はレジストリになりすますことができます。これはワークロードが起動する前に起こるため、ワークロードのイメージ内の証明書を更新しても、ダウンロードは保護されません。

ディストリビューションのCA更新をインストールするか、修正済みのノードイメージでノードを置き換えてください。そのうえで、古い証明書をキャッシュしている対象プロセスを再起動します。これには、コンテナランタイムと、関連するノードやコントロールプレーンのコンポーネントが含まれます。新しく起動した診断ツールは更新後のバンドルを使用していても、長時間稼働しているサービスは古いバンドルを使い続けていることがあります。

コントロールプレーンにも注意が必要です。kubeadmクラスターでは、APIサーバーとコントローラーマネージャーがノードの証明書ディレクトリをマウントします。これらのストアは、外部へのHTTPS接続に使用されることがあります。たとえば、アドミッションWebhookの設定で明示的なcaBundleが省略されている場合、APIサーバーはシステムのルート証明書を使用します。バンドルが指定されている場合は、そのバンドルを別途確認する必要があります。

kubeadmのコントロールプレーンコンポーネントには、サポートされている静的Podの再起動手順を使用してください。API経由でミラーPodオブジェクトを削除しても、その実体であるコンテナは再起動されません。冗長化されたコントロールプレーンでは、1ノードずつ順番に作業し、次へ進む前に正常に稼働していることを確認してください。

あわせて、証明書検証の修正を含むKubernetesおよびランタイムのリリースのうち、該当するものをデプロイしてください。マネージドKubernetesの場合は、コントロールプレーンとノードイメージのロールアウトに関するプロバイダーのガイダンスに従ってください。プロバイダーの更新によって、アプリケーションイメージやカスタムCAバンドルが自動的に置き換えられることはありません。

2. イメージ：コンテナ独自のトラストストア

ノードのCAバンドルを更新しても、そのノード上のコンテナイメージ内の証明書は更新されません。多くのイメージは独自の/etc/ssl/certsを含んでおり、そこにはイメージのビルド時にインストールされた証明書が入っています。

情報開示サイトでは、影響を受ける発行者の証明書を提示するテスト用エンドポイントが提供されています。次のコマンドは、特定のcurlイメージを使ってemSignのエンドポイントを確認します。

kubectl run curl --image=curlimages/curl:8.22.0 --restart=Never --rm -i -- \
  -sS -o /dev/null -w '%{http_code}\n' https://dv-g3b-emudhra.we-have-a-problem.com/

次の比較では、CAパッケージを更新済みの同じノード上で2つのイメージを使用しています。

古いイメージは、イメージ自身のバンドルが修正より前のものであるため、影響を受ける証明書を依然として受け入れます。自分たちでメンテナンスしているイメージについては、CAパッケージを更新し、再ビルドして再デプロイしてください。ベンダーのイメージについては、修正を含むリリースを使用し、稼働中のPodがそれに切り替わっていることを確認してください。

これで確認できるのはcurlの信頼設定です。同じコンテナ内のアプリケーションは別のバンドルやランタイムを使用している可能性があり、このエンドポイントを拒否したからといって、ほかのすべての証明書チェーンがブロックされることの証明にはなりません。

3. ランタイム：アプリケーションの証明書検証

アプリケーションが常にイメージの/etc/ssl/certsを使用するとは限りません。独自の信頼済み証明書を含んでいるランタイムもあります。また、トラストストアに影響を受けるルート証明書がまだ残っていても、侵害された署名鍵を拒否するコードを含んでいるランタイムもあります。

Kubernetesのコントロールプレーンコンポーネントや多くのコントローラーはGoで書かれているため、Goは特に重要です。Go 1.27.3と1.26.10では、侵害された鍵を含む証明書チェーンを拒否するブロックリストがcrypto/x509に追加されました。

3つのGoバージョンでビルドしたテストクライアントで、その違いを確認できます。同じ古いCAバンドルを使った場合の結果は、次のとおりです。

更新済みのクライアントは、影響を受ける証明書を拒否しつつ、対照となる接続は引き続き受け入れています。この保護はアプリケーションにコンパイルされて組み込まれるものです。修正済みのツールチェーンでビルドされたリリースをデプロイするか、自分たちで再ビルドして再デプロイしてください。go.modで宣言されているバージョンからは、デプロイ済みのバイナリをどのツールチェーンがビルドしたのかは判断できません。バイナリのビルドメタデータと、実際の動作の両方を確認してください。

Java、Node.js、Python、Rustのアプリケーションにも、ランタイムごとの確認が必要です。ランタイムのセキュリティガイダンスと、Pythonのcertifiのように別途同梱されているCAパッケージを確認してください。オペレーティングシステムの証明書を更新しても、それらのコピーが更新されるとは限りません。

4. クラスター設定：Kubernetesオブジェクト内のCAバンドル

Kubernetesオブジェクトには、ワークロードやコントローラーが接続の検証に使用するCAバンドルを保持できます。ノードやコンテナイメージを更新しても、保存されているこれらのコピーは置き換えられません。

アプリケーションが信頼済み証明書を受け取る場所を確認してください。

• ConfigMapとSecret：Argo CDのargocd-tls-certs-cm、ca.crtを含むSecret、IstioやKastenが参照するバンドルなど。
• Kubernetes APIの設定：アドミッションWebhook、APIService、CRDのコンバージョンWebhookに含まれるCAバンドルなど。
• アプリケーションの設定：カスタムリソースやHelm valuesのCA設定、trust-managerが配布するバンドルなど。

該当するルート証明書の特定には、情報開示サイトの影響を受けるルート証明書の一覧にあるSHA-256の証明書フィンガープリントを使用してください。明示的に信頼している、影響を受ける中間CA証明書も確認してください。同じ種類のKubernetesオブジェクトに保存されているというだけの理由で、無関係なクラスターやメッシュのプライベートなトラストアンカーを削除しないでください。

trust-managerを使用している場合は、デフォルトのCAパッケージと、リポジトリやタグのオーバーライドを確認してください。v0.25.0までのチャートは、影響を受けるパッケージをデフォルトでインストールします。v0.26.0では修正済みのパッケージがインストールされます。デフォルトのパッケージを更新しても、追加のBundleソースから供給される、影響を受ける証明書は削除されません。

利用可能な修正とアップグレードガイダンス

以下の表は、2026年11月9日時点のスナップショットに基づき、Kubernetesコンポーネント、マネージドクラスター、クラウドネイティブツールに必要な対応をまとめたものです。ロールアウトを計画する前に、リンク先の各プロジェクトのガイダンスで、より新しいバージョンがないか確認してください。カスタムバンドル、補助プログラム、その他のイメージバリアントは、引き続き別途確認が必要です。

Kubernetesとコンテナランタイム

マネージドKubernetes

プロバイダーの更新が提供されているからといって、それが自分のクラスターに適用済みであるとは限りません。コントロールプレーン、ノードイメージ、ロールアウトの状況を確認し、そのうえで、利用者側で管理するワークロードに別途対処してください。

サービスメッシュ、ゲートウェイ、ネットワーキング

証明書、アイデンティティ、ポリシー

デリバリーとサプライチェーン

コンテナビルド、レジストリ、スキャン

オブザーバビリティ、データ、プラットフォーム

まとめ

eMudhraの侵害は、ノードにパッチを適用した後も、Kubernetesのセキュリティ更新が不完全なままになり得る理由を示しています。コンテナは古いCAバンドルを保持し続けることがあり、アプリケーションはランタイム独自の別のストアを使用することがあり、クラスター設定はそのどちらの更新を経ても残り続ける証明書を供給することがあります。また、稼働中のプロセスは、再起動するまで修正が反映されない場合があります。

影響を受けるクライアントごとに、証明書をどのように検証しているかを特定し、該当する更新を適用したうえで、正規の接続が引き続き機能し、かつ侵害されたチェーンが拒否されることを確認してください。検証すべきなのは、実際に使用されているイメージ、設定、補助プログラムを含めた、稼働中のプラットフォームの動作です。