Cloud

概要 IBMとAI最適化クラウドを手がけるスタートアップTogether AIは8月11日、Nvidia製Blackwell世代チップを活用したAI推論クラスターをIBM Cloud上に構築するため、総額2億4000万ドルの複数年契約を締結したと発表した。米国内に構築されるこのクラスターは、Nvidia HGX B300システム(Blackwell Ultra GPUを8基搭載)を中心に約2000基のBlackwell 300チップと、Nvidia Spectrum-Xネットワーキング機器で構成され、2027年前半にIBM Cloud経由で稼働開始する予定。用途はDeepSeekやMiniMaxといったオープンソースAIモデルの推論処理に特化しており、企業がプロプライエタリモデルより低コストで運用できる基盤を提供する狙いがある。 技術的な詳細 各HGX B300マザーボードはBlackwell Ultra GPUを8基搭載し、NVFP4形式で15ペタフロップスの性能を発揮する。サーバーは最低2TBのメモリと56コアCPUを2基備え、GPU間のデータ転送をNvidiaのConnectX-8 SuperNICが、外部トラフィックの制御をBlueField-3データ処理ユニットが担う構成となっている。Together AIは現在AWSなど他社インフラを借りて月間400兆トークンを処理するクラウドプラットフォームを運営しており、メディア生成向け最適化サービスやトークン課金制のProvisioned Throughput、サーバーレス、専用マシン、バッチ処理といった推論特化の5段階サービスティアを既に提供している。今回のIBMとの契約で得る計算資源は、これらサービスの提供拡大に充てられる計画だ。 背景と反響 Together AIはサンフランシスコを拠点に、企業がオープンモデルを低コストで運用できるプラットフォームを展開しており、2026年7月には80億3000万ドルの企業価値評価を受けたばかり。今回のIBMとの契約は、Nvidiaも出資した8億ドルの資金調達ラウンドから数週間後というタイミングでの発表となった。Together AIの最高収益責任者Kai Mak氏は「少なくとも2〜3カ月前には売り切れる見通しだ」と強い需要を示唆し、CEOのVipul Ved Prakash氏も「このクラスターにより、より多くの企業に本番運用レベルの推論をより速く提供できる。オープンソースAIを企業にとって当然の選択肢にするための大きな一歩だ」とコメントしている。 展望 今回の提携は、学習済みモデルを実際の応答生成に使う「推論」がクラウドコンピューティング需要の主要な牽引役になりつつあることを示す事例といえる。オープンソースモデルの低コスト運用を求める企業ニーズの高まりを受け、クラウド事業者やチップメーカー各社が推論特化インフラへの投資を加速させる動きが今後さらに広がる可能性がある。

概要 Googleは2026年8月10日、Google Kubernetes Engine(GKE)向けに「ClusterNetworkPolicy(CNP)」のプレビュー提供を開始した。CNPはKubernetes SIG-Network(SIG-Policy Working Group)が策定したオープンソースのAPI仕様で、従来の名前空間単位のNetworkPolicyとは異なり、クラスタ全体を対象にネットワークトラフィックを制御できる。GKE 1.36以降で利用可能。決済処理など機密ワークロードを扱う名前空間の隔離や、kube-dnsのような重要な内部サービスの保護を、開発者側の設定に左右されず一貫して強制できる点が特徴だ。プロプライエタリな独自拡張ではなく、Kubernetesコミュニティおよび実装パートナーであるCiliumコミュニティと協調して設計されており、異なる環境間でもポリシー設定を再利用できるポータビリティを備える。 技術的な詳細 CNPの中核は、Admin Tier(管理者層)・Network Policy Tier(ネットワークポリシー層)・**Baseline Tier(ベースライン層)**という3層構造による階層的なポリシー評価にある。評価はAdmin Tierから順に行われ、最上位のAdmin Tierは他のすべてのポリシーに優先し、バイパス不可能なコンプライアンス・セキュリティ要件をRBACで厳格に強制する。中間のNetwork Policy Tierは従来通り開発者がアプリケーション固有のポリシーを名前空間内で定義する層で、Admin Tierのルールには従属する。最下層のBaseline Tierはクラスタ全体のデフォルト動作(例えばゼロトラストに基づく「Deny All」)を設定し、名前空間スコープのポリシーによって上書き可能となっている。この階層構造により、従来のNetworkPolicyで起こり得た平坦な構造ゆえの設定競合を排除し、決定論的な評価を実現している。 Admin TierのルールはAccept(トラフィックを明示的に許可)、Deny(明示的に拒否)に加え、新たにPassという第3のアクションをサポートする。Passはトラフィックの最終的な許可・拒否の判断を下位層、すなわち開発者の名前空間ポリシーに委譲する仕組みで、セキュリティチームがグローバルルールでトラフィックを検査しつつ、最終決定は開発者側に委ねるといった柔軟な運用を可能にする。APIはpolicy.networking.k8s.io/v1alpha2というAPIグループで提供され、名前空間スコープの標準NetworkPolicy(networking.k8s.io)とは別のリソースとして区別される。マニフェストではtier(Admin/NetworkPolicy/Baseline)、priority(同一層内の優先度)、subject(対象となるPodや名前空間のセレクタ)、ingress/egressルールなどを指定する。 具体的なユースケースとしては、決済処理や規制対象データを扱う名前空間へのアクセスをAdmin Tierで一括してDenyし、開発者側の許可設定では上書きできないようにする「機密ワークロードの隔離」、kube-dnsなど内部運用上重要なサービスへのアクセスをAdmin TierのAcceptルールで維持し、名前空間ポリギーの誤設定の影響を受けないようにする「コアサービスの保護」、そしてIPアドレス範囲(IPv4の0.0.0.0/0やIPv6の::/0など)を用いたegressトラフィックの制御による不正なデータ流出防止が挙げられている。利用にはGKE 1.36以降のクラスタが必要で、現時点ではプレビュー機能として提供されている。

概要 AWSはAIエージェント基盤「Amazon Bedrock AgentCore」に、新たな2つの機能を追加した。1つはセッション内でのエージェントの過去のアクション履歴を踏まえて各リクエストを評価する、ステートフルな認可制御「temporal policies」と、モデルやツールへのトラフィックを制限する「rate limiting」機能。もう1つは、ユーザー自身のAmazon EC2インスタンス上でインフラ管理なしにエージェントを実行できる「runtime instances」機能の一般提供(GA)開始である。両機能はいずれもAIエージェントを本番環境で安全かつ柔軟に運用するための基盤強化と位置づけられる。 temporal policiesによる文脈認識型の認可制御 temporal policiesの背景にある問題意識は、「単一のツール呼び出しはそれ単体では安全でも、それ以前に何が起きていたかによっては有害になり得る」という点にある。従来の認可制御は個々のリクエストを独立に評価することが多いが、AIエージェントは複数ステップにわたって自律的に行動するため、直前までの操作履歴を無視した判断では不十分になるケースが出てきていた。 temporal policiesは、こうした課題に対応するため、セッション内での過去のアクションをコンテキストとして各リクエストを評価する。具体的な用途としては、ワークフローの実行順序を強制すること、ツールの引数が先行するコール出力と完全に一致することを要求すること、特権的なアクションを実行する前に人間による承認を必須とすること、扱うデータの鮮度を維持することなどが挙げられている。 あわせて提供されるレート制限機能は、ツール・モデル・ゲートウェイに接続されたエージェントへのトラフィック量を、ユーザー単位またはグループ単位で制御するものだ。OAuthやAWS IAMによるスコープ設定に対応し、全ターゲットタイプへのリクエスト数、推論ターゲットへのトークン数、長時間セッションの上限などを細かく設定できる。これにより、ダウンストリームサービスの可用性確保と、利用者間での公平なリソース配分の両立を図る狙いがある。 runtime instancesの一般提供開始 同時に発表されたのが、ユーザー自身のEC2インスタンス上でエージェントを管理なしに実行できる「runtime instances」機能の一般提供(GA)開始である。既存のサーバーレス型ランタイムが最大8時間程度の短時間セッション向けであったのに対し、runtime instancesは最大14日間に及ぶ長時間セッションに対応する。GPU加速、メモリ最適化、計算最適化など、EC2インスタンスファミリーの全範囲から選択可能で、既存のマイクロVM型ランタイムと組み合わせて使うこともできる。プロビジョニングやパッチ適用、スケーリング、ライフサイクル管理といった運用面はAWSが担うため、利用者はインフラ管理の負担を負わずに済む。提供リージョンは米国東部2地域、米国西部、アジア太平洋4地域、欧州2地域の計9地域で、料金はコンピュートのプロビジョニング管理費に加えて通常のEC2利用料が発生する形となる。 今後の展望 長時間稼働・高負荷な処理を要するAIエージェントのニーズが高まる中、AWSは今回の機能追加により、セキュリティ・ガバナンス面(temporal policies、レート制限)とインフラの柔軟性(runtime instances)の両面からAgentCoreの実運用対応力を強化した形だ。特にtemporal policiesは、単発のリクエスト単位ではなくセッション全体の文脈を踏まえた認可制御という、エージェント特有のリスクに対応する仕組みとして、他クラウドベンダーの同種サービスにも今後波及する可能性がある。

概要 ビットコインマイニング企業のRiot Platformsは8月11日、AI開発企業Anthropicとの間で大型のデータセンター賃貸契約を締結したと発表した。テキサス州ロックデールにあるRiotの拠点で191メガワットのデータセンター容量をAnthropicに提供する内容で、契約期間は20年、基本契約額は91億ドルに上る。さらに5年間の延長オプションを2回行使した場合、契約総額は最大161億ドルに達する見込みだ。発表を受けてRiotの株価は寄り付き前の取引で20%超急騰し、市場からの高い期待を裏付けた。 契約の詳細と経済効果 今回の契約により、Riotは基本契約期間だけで73億〜82億ドルの純営業利益を見込んでいる。データセンターの展開は2027年12月に開始し、2028年6月までに全面稼働を目指す計画だ。Riotの直近の四半期決算では、収益が前年比14%増の1億7,420万ドルとなった一方、データセンター関連収益はまだ2,320万ドルにとどまっており、Anthropicとの契約が今後の収益構造を大きく変える可能性がある。 業界の背景 ビットコインマイニング業界では、採掘難易度の上昇や価格変動によるマイニング収益のボラティリティを回避するため、余剰電力インフラを活用したAIデータセンター事業への転換が加速している。Riotに先立ち、同業のBitdeerもノルウェーの拠点をAI企業向けに提供しており、AnthropicはVolta Infraとの間で100億ドル規模のデータセンター契約を締結している。AI需要の急拡大がマイニング企業の事業戦略を根本から変えつつあることを示している。電力インフラと土地をすでに保有するビットコインマイナーは、AI企業にとって短期間で大規模な電力供給が可能なパートナーとして注目されており、今後も同様の提携が相次ぐ可能性がある。 今後の見通し AnthropicにとってもRiotとの契約は、急増する計算需要に対応するためのインフラ確保策の一環とみられる。生成AIモデルの学習・推論に必要な電力需要は世界的に逼迫しており、既存の電力網に接続済みの施設を持つ企業との長期契約は、データセンター新設に伴う許認可や送電網増強の遅延リスクを回避する有効な手段となっている。今回の契約が市場から高く評価されたことで、他のビットコインマイナーもAI企業との提携交渉を本格化させる展開が予想される。

概要 東北電力は7月31日、宮城県宮城郡七ヶ浜町にコンテナ型データセンター「宮城AIデータセンター」を開所した。ゲットワークスとの協業により実現した施設で、NVIDIA H200・B300といった次世代型GPUサーバー向けのハウジングサービス提供を開始している。生成AIの急速な普及によりGPUサーバーの需要が拡大する中、すでに構築分の約50%が契約済みとなっており、「引き合いは大きい」状況だという。 七ヶ浜町は東北電力の仙台火力発電所が置かれてきた土地であり、同社にとって歴史的なつながりを持つ地域でもある。今回、遊休地を活用してデータセンターを設置したことで、気候や冷却条件などを踏まえて適地を選んで展開できる利点があり、新たなデータ産業の拠点として期待されている。 技術的な詳細 施設はラック単位・コンテナ単位のいずれでも利用可能で、耐荷重は2t/平方メートル。受電はコンテナあたり50kWで、需要に応じて増強できる設計となっている。空調はN+1の冗長構成を採用し、現在は空冷方式だが将来的には水冷方式への対応も計画されている。通信回線は現状1G×2回線だが、2027年度中に10G対応へ拡張される予定だ。セキュリティ面ではICカードによる扉の管理と監視カメラの設置によって確保されている。GPUサーバーについては顧客の要望に応じて使用電力などのカスタマイズにも対応するとしている。 今後の展望 東北電力の常務執行役員は、「AIの開発から運用までを支える基盤を提供していく」とコメントし、同社が手がける既存のGPUクラウドサービスと組み合わせた展開を示唆した。東北電力の担当者は、コンテナ型データセンターの利点として「数カ月での環境構築が可能」な点を挙げ、協業するゲットワーク代表は、GPUサーバーが届いたタイミングですぐに稼働できる点をメリットとして強調している。今後は水冷サーバーへの対応準備を進めるとともに、拡張性を備えた設計を活かして複数地域への展開も予定されており、国内の電力会社によるAI関連インフラ投資の広がりを示す事例となりそうだ。

概要 Cloudflareは、社内でエージェントやアプリケーション、業務ワークフロー向けに使ってきたAIプラットフォーム「Cloudflare OS」をApache 2.0ライセンスの下でGitHub上に公開した。名称に「OS」を含むものの、これは従来型のオペレーティングシステムではなく、AIエージェントを組織のコンテキストと結びつけて動かすためのワークスペース基盤である。Cloudflareは既にこの仕組みを自社の内部業務で運用しており、今回それを外部の開発者やエンタープライズにも利用できる形で公開した。 技術的な詳細 Cloudflare OSは大きく3つの要素で構成される。1つ目は、企業が整理したコンテキストやスキルをもとにエージェントがコードを実行できる、隔離されたランタイム環境としての「エージェントワークスペース」。2つ目は、社内データやサービスへのアクセスを安全に制御するための「セキュリティ・ガバナンスフレームワーク」。3つ目は、ユーザーが自ら構築・共有・修正できる「モジュール型アプリプラットフォーム」である。利用の起点はブラウザ上での対話であり、そこから始まったやり取りがドキュメントやアプリ、さらには継続的なワークフローへと発展していく設計になっている。組織全体の目標に沿った形でエージェントを動かせる点が、他の汎用的なエージェントツールとの差別化要因とされている。 背景と今後 Cloudflareはこれまでもエッジコンピューティングやセキュリティ製品を中心に事業を展開してきたが、AIエージェントの実行基盤という新たな領域を、まず自社の内部システムとして構築・運用し、その成果をオープンソースとして還元する形を取った。Apache 2.0という商用利用に寛容なライセンスを選んだことで、企業が自社のガバナンス要件に合わせてカスタマイズしながら導入しやすくなっている。ただし、公開時点の発表ではオープンソース化の戦略的な狙いや、今後のロードマップについて詳しい説明はなされておらず、コミュニティやエンタープライズユーザーからの反応、そして実運用でのユースケースの広がりが今後の焦点になりそうだ。

概要 CNCFのインキュベーションプロジェクトであるKubernetes向けコスト管理OSS「OpenCost」が、バージョン1.121.0でLLM推論基盤「llm-d」との統合を果たし、GPU・トークン単位で推論コストを可視化する「AI Inference Costs v1」機能を追加した。プラットフォームチームの多くは、GPUコストの上昇や数十億トークン規模の処理量は把握していても、1トークンあたりの実際のコストが不透明という課題を抱えていた。自社ホスティングとSaaS APIのコスト比較やチーム別のAI予算消費の追跡もできていなかった中、今回の機能はこうしたFinOpsニーズの高まりに応える初の同種機能となる。 技術的な詳細 統合アーキテクチャは、vLLMが発行するトークンスループット（プロンプトトークン数・生成トークン数）や処理時間のメトリクスと、OpenCostが持つ既存のGPU割り当てエンジンを組み合わせる形で実現されている。Prometheus向けに新たにllm_total_hourly_cost（モデル単位の時間あたりコスト）やllm_cost_per_million_tokens（入力/出力トークン別の百万トークンあたりコスト）といったメトリクスが公開され、model_nameやcost_basis（利用ベースか割り当てベースか）といったラベルが付与される。 コスト計測は「割り当てベース」と「利用ベース」の2軸で行われる点が特徴的だ。割り当てベースはGPUメモリ、推論時のコンピュート、ゲートウェイやKVキャッシュなどインフラ全体にかかる運用コストを反映する一方、利用ベースは実際の推論処理に消費された分のみを計上し、KVキャッシュヒットの効果も反映する。両者の比率（利用ベースコスト÷割り当てベースコスト）が「利用率」となり、たとえば割り当てベースが百万トークンあたり4.00ドル、利用ベースが1.00ドルなら利用率は25%と算出される。 記事はここで、利用ベースコストのみを見て自社ホスティングとSaaS APIを比較する「落とし穴」を指摘している。利用ベースコストが百万トークンあたり1.00ドルの自社モデルは、2.00ドルのSaaS APIより一見有利に見えるが、利用率が25%であれば実際の割り当てベースコストは4.00ドルとなり、SaaSの方が経済的に優位になる。自社ホスティングが競争力を持つには、おおむね50%以上の利用率が必要になるという。llm-dデプロイメント周辺の推論スケジューラ（EPP）、ゲートウェイプロキシ、最大18TBに達するティアードKVキャッシュストレージ、ワークロード変種オートスケーラーといったコンポーネントも、OpenCostの共有ラベル機構により自動的にコスト割り当ての対象となる。 この機能はIBM ResearchのSima NadlerとOpenCostメンテナーのAlex Meijerが共同で解説しており、109基のGPUと30個のデプロイ済みAIモデルを持つクラスタで検証済みだという。今後はOpenCost側で無駄なGPU容量の測定やLLM固有のアイドル検出、UI統合、チーム別コスト属性付けなどが、llm-d側ではワークロード/テナント単位のメトリクス収集などが計画されている。両プロジェクトはオープンソースとして公開されており、モデルの経済性評価やチャージバック/ショーバック報告、過小利用モデルの特定などへの活用が見込まれる。

概要 AWSは、AIエージェントの行動を実行時に検証するためのガバナンス言語「Dogwood」をApache 2.0ライセンスでオープンソース公開した。同時に、IDE「Kiro」向けに複数のエージェントが協調して作業を進める新機能「Kiro Crew」も発表している。ただし後者については、オーケストレーション層のみがオープンソース化され、基盤モデルとの通信や推論を担う「エージェントハーネス」そのものは非公開のまま据え置かれた。両者はいずれも、企業が自律的に動くAIエージェントをどこまで信頼し、どう統制するかという課題に対するAWSの回答と位置づけられる。 Dogwoodの技術的な仕組み Dogwoodは、AWSの既存の認可言語「Cedar」を土台に、時間軸を扱う機能を追加したものだ。Cedarは高速で読みやすく自動推論分析も可能だが、単一のリクエストをその場限りで評価する仕組みに限定されていた。Dogwoodはこれを拡張し、ランタイム検証分野に由来する「メトリック一階時間論理(MFOTL)」に基づいて、過去のイベント履歴を参照しながらポリシーを評価できるようにしている。 具体的には、指定した時間内の過去イベントを検索するformerly、時間窓内のイベント数を数えるcount_within、異なる値の数を数えるcount_distinct_within、金額などを合計するsum_withinといった演算子を備える。これにより「直前1時間以内に承認された取引のみ売却を許可する」「1時間以内に5回を超える送金を禁止する」「1時間の送金総額を5,000ドルまでに制限する」「1時間以内に異なる受取人最大3人までしか送金できない」といった、時間の経過を伴う複雑なガバナンスルールを表現できるようになった。なお、ポリシーはレスポンスではなくリクエストイベントを基準にカウントすべきだとされており、これは複数の並行リクエストを発行して制限を回避される攻撃を防ぐための設計上の要点だ。 既存のCedarポリシーはそのまま書き換えなしで利用でき、必要に応じて時間条件句を追加していく段階的な移行が可能という。AWSはAgentCore Policyレイヤーにも対応を組み込み、Model Context Protocol(MCP)のツールマニフェストからアクションスキーマを自動生成する仕組みも用意した。今後は固定時間枠に基づく絶対時間対応や、承認の完了など将来の保証を扱う活性検証、複数エージェント間の協調ルールへの対応も計画されている。 Kiro Crewとオープンソースの線引き Kiro Crewは、開発者が別の作業をしている間もバックグラウンドで動き続ける永続的なエージェントプラットフォームで、元々はAmazon社内で「MeshClaw」というプロジェクト名で開発されていたという。今回のオープンソース化では、ハートビート監視やwebhookによるスケジューリング、コンテキストを保持するメモリ管理、Agent Client Protocol(ACP)経由のマルチエージェント協調、OSサンドボックスや監査ログによるセキュリティといったオーケストレーション層がApache 2.0で公開された。 一方で、基盤モデルとの通信やツール呼び出し、推論を担う「エージェントハーネス」自体、Cedarベースの権限ポリシー実装、Kiroクレジットの消費ロジックといった中核部分は非公開のままだ。AWSのVP Deepak Singh氏は「ハーネスはオープンソース化しない」と明言しており、この方針は、AWSが自社の「オープン実装」ではなく標準化された「オープンプロトコル」(ACPなど)を軸に据えていることを示している。 今後の注目点 Forbesの分析では、企業がKiro Crewの採用を検討する際に確認すべき点として、監査ログの署名方式の詳細が未発表であること、オーケストレーション層とハーネス層という2層のポリシーが競合した場合の挙動、Kiroクレジットの消費管理という運用コスト面、そして他のACP互換ランタイムへの移植可能性が挙げられている。オーケストレーション層で競争優位性を手放す一方、推論エンジンと利用料金でマネタイズを確保するという線引きは、AIエージェント関連ツールを手がけるベンダー各社が今後どこまでをオープンにするかを占う一例として注目される。

概要 Anthropicは8月10日、資産運用大手のMacquarie Asset Management、シンガポール政府系投資会社のGICと共同で、AI向けデータセンターインフラを大規模に開発・運営・賃貸する新プラットフォーム「Theseus Infrastructure」を設立すると発表した。MacquarieとGICが施設の株式資本の大部分を出資・所有し、Anthropicは長期契約のもとで各拠点の主要テナント(アンカーテナント)となる。初期段階では米国内での拠点開発に焦点を当てる方針で、各施設はAnthropicの拡大するコンピュート需要に合わせて専用設計される。 出資・体制の構造 今回のスキームでは、Macquarie Asset Managementが運用するファンドとGICが資金の大半を拠出してTheseus Infrastructureを所有し、Macquarieが持つ大規模デジタルインフラの開発・資金調達・運営に関する専門知識と、GICのグローバルなインフラ投資経験を組み合わせる。Anthropicは自ら施設を保有・建設するのではなく、長期契約に基づく主要テナントとして稼働容量を確保する立場を取る。この形態は、巨額の設備投資負担を投資家側と分担しつつ、AI企業が計算資源の確保を優先するという、近年のハイパースケーラー各社によるデータセンター調達戦略とも共通する構図といえる。 地域社会への配慮と経済効果 各拠点の開発には大規模な資本投下が伴い、建設段階での雇用に加え、稼働後も恒久的な運用職が創出される見通しだ。あわせてAnthropicは、データセンター稼働に伴い周辺地域の消費者が直面しうる電気料金の上昇分を自社で負担することを表明しており、地域社会への影響に配慮する姿勢を示している。データセンターの急拡大に伴う地域電力需給や住民への負担は米国各地で議論となっており、今回の取り組みはそうした懸念に応える意図もあるとみられる。 背景と今後の見通し AnthropicのClaudeシリーズをはじめとする大規模言語モデルの需要拡大により、AI企業各社は計算基盤の確保を急いでいる。Anthropicにとって今回のパートナーシップは、自社のバランスシートに大きな設備投資負担を抱えることなく、必要なコンピュート容量を長期的に確保する手段となる。具体的な投資規模や第一号拠点の所在地、稼働開始時期などの詳細は今後明らかにされる見込みで、Theseus Infrastructureが米国外への展開を含めどのように拡大していくかが注目される。

概要 Red Hat Advanced Cluster Management for Kubernetes(ACM)に、CVSSスコア9.9(最高レベル)という極めて深刻な権限昇格の脆弱性CVE-2026-10090が発見された。この脆弱性の危険性は、必要とされる権限の低さにある。攻撃者は名前空間スコープの「編集」権限さえ持っていれば、クラスタ全体の管理者権限であるcluster-adminロールにまで昇格できてしまう。マルチテナント環境で複数のチームやユーザーに限定的な権限を委譲しているKubernetesクラスタにとって、テナント分離の前提そのものを覆しかねない問題であり、ACMを本番環境で運用する組織は早急な対応が求められる。 攻撃の仕組み この脆弱性は「confused deputy(混乱した代理人)」問題として分類される。ACMのApplication Subscriptionコントローラーが、本来は低権限のユーザーが直接実行できない操作を、コントローラー自身の昇格された権限で代行してしまうことが根本原因だ。具体的な攻撃手順は次の通りとなる。まず、名前空間スコープの編集権限を持つ攻撃者が、自身の管理下にある悪意あるHelmリポジトリを指し示す「Channel」オブジェクトを作成する。次に、その悪意あるChannelを参照する「Subscription」オブジェクトを作成すると、脆弱なコントローラーが本来ユーザーには許可されていない昇格権限を用いて、指定されたHelmチャートを自動的にデプロイしてしまう。このチャートの中にClusterRoleBindingリソースを仕込んでおけば、任意のServiceAccountにcluster-adminロールを付与でき、結果としてクラスタ全体を掌握できる。CVSSベクトルは「AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H」で示される通り、攻撃元区分はネットワーク経由、攻撃条件の複雑さは低く、ユーザーの関与も不要という、悪用が容易な条件が揃っている。 影響範囲と対応状況 脆弱性が存在するのは、Red Hat Advanced Cluster Management for Kubernetes 2に含まれる「rhacm2/multicluster-operators-subscription-rhel9」コンポーネントである。ACMはマルチクラスタ環境の統合管理を担う中核コンポーネントであるため、影響を受けるとクラスタ単体にとどまらず管理下の複数クラスタ全体に波及するリスクがある。特に懸念されるのは、報道時点でRed Hatが「現時点でRed Hatの製品セキュリティ基準を満たす緩和策が存在しない(“no mitigation currently meets its product-security criteria”)」と明言している点で、正式な修正パッチはまだ提供されていない。 推奨される暫定対策 パッチが提供されるまでの間、Red Hatおよびセキュリティ研究者は以下の暫定対策を推奨している。まず、RBAC設定を見直し、必要最小限の権限のみを付与する最小権限の原則を徹底すること。特にChannelおよびSubscriptionオブジェクトを作成できるユーザーやグループを厳格に制限することが重要となる。あわせて、参照を許可するHelmリポジトリの所有権や出所を確認し、信頼できないリポジトリを指すChannelの作成を防ぐこと。さらに、ClusterRoleBindingの作成など、クラスタスコープのリソースに対する変更を継続的に監視し、異常なロール付与を早期に検知できる体制を整えることが望ましい。ACMを利用する組織は、Red Hatからの正式なセキュリティアドバイザリおよびパッチ提供状況を注視し、公開され次第速やかに適用する必要がある。