Red Hat OpenShift 4.20 コントロールプレーンにおけるポスト量子暗号化のサポートの詳細

量子コンピューティングの時代が目前に迫っており、その膨大な処理能力はデジタル世界の暗号化基盤に大きな脅威をもたらします。この記事では、Red Hat OpenShift 4.20 におけるポスト量子暗号化 (PQC) の新たなサポートについて、また Kubernetes コントロールプレーンのコアコンポーネント (apiserver、kubelet、scheduler、および controller-manager) をどのように強化するのかに焦点を当てて説明します。etcd は古いバージョンの Go を使用しているため、これらとは別に扱われます。

量子脅威

RSA や 楕円曲線暗号 (ECC) など、現在広く使用されている公開鍵暗号システムは、セキュリティが強化されたオンライン通信の基盤を形成します。これらのシステムは、大規模な量子コンピュータによる攻撃に対して脆弱ですが、大規模な量子コンピュータは、これらのアルゴリズムの基礎となる数学的問題を驚くほどの速度で解決できます。これにより、攻撃者が今日暗号化したトラフィックを記録しておき、将来的に強力な量子コンピューターにアクセスした時点でそれを復号化して生じる攻撃のリスクが発生します。同じことは、攻撃者が今コピーを作成して後で復号化しようとする保管中のデータにも生じます。

この脅威に対抗するため、PQC の分野が登場し、従来のコンピュータと量子コンピュータの両方からの攻撃に耐性を持つ新しい暗号化アルゴリズムが開発されました。

Kubernetes および OpenShift における PQC

Red Hat OpenShift は CNCF (Cloud Native Computing Foundation) 認定の Kubernetes ディストリビューションであり、Kubernetes は Go プログラミング言語で作成されています。したがって、OpenShift での PQC サポートは Go から始まっています。

Go 1.24 リリース は、X25519MLKEM768 ハイブリッド鍵交換メカニズムのサポートを導入したことにより、重要なマイルストーンを迎えました。X25519MLKEM768 は、従来の X25519 (楕円曲線 Diffie-Hellman) と ML-KEM-768 (ポスト量子アルゴリズム) を組み合わせたハイブリッド鍵交換です。最終的な共有シークレットは、2 つのメカニズムを組み合わせて派生します。純粋な ML-KEM は、耐量子性を実現するために、格子ベース暗号に完全に依存しています。X25519MLKEM768 は、ML-KEM の量子耐性と X25519 の従来のセキュリティを同時に提供します。

現時点では、ハイブリッドアプローチの方がより堅牢です。ML-KEM は 2024 年 8 月に標準化されたばかりなので、暗号化の観点からは「まだ新しい」とみなされています。ML-KEM の格子仮定に対する予期しない従来型の攻撃 (量子ではなく通常の暗号解析) が発見された場合、純粋な ML-KEM デプロイメントは失敗します。ハイブリッドであれば、X25519 が有効です。

トランスポート層セキュリティ (TLS) セッション用の共有シークレットは、コンポーネントのアルゴリズムの少なくとも 1 つが影響を受けていない限り、期待されるセキュリティーレベルを提供します。これは、PQC をエコシステムに導入するための堅牢で前方互換性のある方法を提供します。

PQC の OpenShift コントロールプレーンへの適用

OpenShift 4.20 での PQC のサポートは、各 Kubernetes コンポーネントで特定の PQC フラグを設定するだけのものではありません。むしろ、これらのコンポーネント間の TLS 通信の強度が重要となり、これは基盤となる Go のバージョンとその暗号ライブラリによって実現されます。

PQC のサポートにより、OpenShift のコアコンポーネント間の通信のセキュリティーがどのように強化されるかを示します (etcd のステータスについては、以下で別途説明します)。

• API サーバー：Kubernetes コントロールプレーンの中心ハブであり、API サーバーとのすべての通信は重要なセキュリティポイントです。ML-KEM 対応の TLS により、コントロールプレーンの通信は、暗号化されたトラフィックを記録し、将来復号化しようとする攻撃から保護されます。
• Kubelet：kubelet は各ノードで実行され、API サーバーと通信してノードのステータスを更新し、Pod 仕様を受信します。この通信は、セキュリティ強化のためにハイブリッド PQC 鍵交換を組み込み、リンクの整合性と機密性を検証するのに役立ちます。
• スケジューラーおよび controller-manager：スケジューラーと controller-manager は API サーバーと継続的に通信して、スケジューリングの決定を行い、クラスタの状態を管理します。これらの対話も ML-KEM 対応の TLS が保護し、アプリケーションの実行を維持するロジックや運用のセキュリティを強化します。

Red Hat の見解

多くの業界規制では 2035 年まで PQC を義務付けていませんが、Red Hat は PQC への移行を積極的に進めています。最近の記事「Preparing your organization for the quantum future (量子未来に向けた組織の準備)」では、PQC の取り組みを始めることの重要性を強調しています。さらに、PQC を Red Hat Enterprise Linux (RHEL) に統合する作業は、OpenShift の方向性を示す強力な指標にもなっています。OpenShift 4.20 に PQC 機能を組み込むことは、大きな前進となります。

Go バージョンの不一致

管理者にとって重要な考慮事項は、クラスター内の異なるコンポーネント間で Go バージョンの不一致が発生する可能性があることです。たとえば、ML-KEM 対応の Go バージョンで構築された kubectl クライアントが古い API サーバーと通信する場合、TLS ハンドシェイクは従来の暗号化アルゴリズムにダウングレードする可能性があります。これにより、明示的な警告なしに PQC 保護が失われる可能性があります。したがって、OpenShift 環境内のすべてのコンポーネントが、PQC をサポートする互換性のあるバージョンを実行していることを確認することが不可欠です。

etcd について

コントロールプレーンのコア・コンポーネントについては、ML-KEM 対応の TLS によるメリットがありますが、etcd の場合は独自のロールと開発理念に根差しているために事情が異なります。クラスター全体の信頼できる情報源としての etcd の絶対的な優先事項は、安定性、データの整合性、パフォーマンスです。etcd プロジェクトは、Kubernetes に比べて意図的に保守的な Go バージョン管理スケジュールを維持しています。多くの場合、Kubernetes プロジェクトは新機能やパフォーマンスの改善内容を迅速に活用するために最新の Go リリースを採用しますが、etcd チームは安定性を優先するため、より古い、実績のある Go バージョンを維持します。このような意図的な遅れにより、広範なコミュニティ全体が、新しい Go ランタイムの潜在的な問題を、etcd などの重要なコンポーネントに導入される前に徹底的に検証できます。

PQC サポートが即座に提供されないのは見落としではなく、この安定性優先のアプローチがもたらす直接的な結果です。Go 1.24 で導入された PQC アルゴリズムを etcd で公式にサポートするには、該当の Go バージョンを etcd の安定したリリースブランチに導入する必要がありますが、この etcd では現在も Go 1.23 を使用しています。このプロセスでは、Raft 合意プロトコル、I/O レイテンシー、またはリカバリー操作に悪影響がないことを確認するために、広範囲にわたる検証を行います。今後のリリースで etcd が量子安全性のサポートが予定されています。

今後の道のり

OpenShift 4.20 への PQC の統合は、クラウドネイティブ・コンピューティングの量子対応の未来を築くという Red Hat のプロアクティブなアプローチを証明するものです。デジタル署名と証明書については、PQC はまだ初期段階にありますが、TLS でのハイブリッド鍵交換の実装は重要な最初のステップとなります。