Kubernetes Node への侵害：SPIFFE／SPIRE が引き起こす共有ノード全体への不正アクセス

One Compromised Kubernetes Node Can Expose Every Workload Identity Running on It

2026/09/17 CyberSecurityNews — 攻撃者により root 権限を取得された Kubernetes ノードが ID 侵害の起点となり、他のワークロードを装う悪意あるプロセスが認証情報を取得することで、1 つの侵入経路から共有ノード全体へアクセスを拡大することが、Unit42 の研究結果として示されている。この問題が影響を及ぼすのは、SPIFFE／SPIRE の導入環境であり、そこでは、長期間有効なシークレットが有効期間の短いワークロード ID に置き換えられる。これらの認証情報により、サービス間における相互の ID 証明が実行されている。

このモデルは、ノードが信頼できることを前提としているが、攻撃者が OS を制御した時点で、その前提は崩れる。Unit42 のアナリストが特定したのは、root 権限を持つ攻撃者が、ワークロードの検証に使用される Linux cgroup のデータを変更する方法である。

Palo Alto Networks はレポートで、「この手法により、ローカルの SPIRE エージェントが、同じノード上に存在する別のワークロードの ID を、攻撃者が制御するプロセスへ発行する可能性がある。ただし、この手法が実環境で悪用されている事例は確認されていない」と説明している。

有効なワークロード ID が攻撃者に取得されると、一般的な窃取済み認証情報では利用できない、信頼されたアクセス経路が開かれる可能性があり、正規のサービスを装う攻撃者は、内部サービスへのアクセス認証／保護されたデータの要求／アプリケーション間の横展開を実行できる。

Kubernetes 設定ミスの悪用事例が示すのは、ノードのセキュリティと ID の制御を、別々の問題として扱えない理由である。

侵害された 1 台の Kubernetes ノード

SPIFFE は各ワークロードに対して、名前／有効期間の短い SPIFFE Verifiable Identity Document (SVID) および、その SVID を検証する Trust Bundle を割り当てる。アプリケーションはローカルの SPIRE エージェントへ SVID を要求し、エージェントはプロセスの属性を確認してから、相互 TLS 接続／トークンベースのアクセスで用いられる認証情報を返す。Kubernetes 上では、エージェントがプロセスの cgroup パスを検査し、コンテナ／Pod と関連付けた後に、Namespace／ServiceAccount の情報を収集する。

エージェントは、これらの情報を登録ルールと比較し、値が一致すると、ワークロードの SVID などの必要な情報を返す。Unit42 が実証したのは、root 権限を取得すると、この結果を変えられることであり、標的に似た cgroup パスを作成／操作する攻撃者は、そこに自身のプロセスを追加できる。したがって、エージェントが標的の Selector と一致すると、その認証情報が悪意のプロセスへ受け渡される可能性がある。

これは、侵害後の活動に用いられる手法であり、単独でクラスタを侵害するリモートの脆弱性ではない。ただし、影響を受けたノード上の、すべてのワークロード ID を漏洩したものとして扱うべき、きわめて深刻な状況に陥る。

そのため、侵害されたノードに関係する Kubernetes NodeRestriction の脆弱性についての報告が示す影響は、最初の侵入経路だけに留まらない。

ノード境界の防御

研究者たちが開発したテストツール Spooffe は、ノードのスキャン／実行中のワークロードの cgroup パスの再現／ローカルエージェントへ対応する ID を要求するものだ。このツールは、管理者レベルの権限が侵害された後の、防御側による影響範囲の測定を支援する一方で、有効期間の短い認証情報だけでは、ホストレベルのセキュリティ侵害を解決できないことも示している。

ユーザー組織は、ノードでの root 権限の取得を、そのノードを対象とするすべての暗号学的 ID へのアクセスと見なす必要がある。つまり、ID システムと同等の重要性でワーカーノードを保護し、管理者権限を厳格に制限した上で、プロセス／コンテナ／cgroup に対する想定外の変更を監視する必要がある。

Unit42 が示したのは、ホストの制御に対して特権コンテナが直接到達する経路になる可能性であり、Docker／Kubernetes の設定ミスを攻撃者が悪用した事例から得られた教訓とも一致する。

チームにとって必要なことは、可能な範囲での特権コンテナの禁止／ホストの直接マウントとホストネットワークの利用制限／コンテナランタイム・インターフェースへのアクセスの厳格な制御などである。登録ポリシーに関しては、root 権限を持つ攻撃者が模倣できる Selector だけに依存すべきではなく、具体的なポリシー設計／定期的なレビュー／多層的な制御などにより、1 つのワークロードの侵害からの ID 侵害の全域への拡大を防止すべきである。

防御側に求められるのは、ノードを共有する機密性の高いワークロードを特定することであり、特にデータベース／クラウド／導入環境に対する広範な権限を持つサービスに注意する必要がある。価値の高いワークロードの分離／最小権限の適用により、ノードが侵害された場合の被害の軽減が可能になり、Kubernetes の本番クラスタを保護するためのガイダンスでも、強固なアクセス制御／セグメンテーション／継続的な監視の重要性が強調されている。

重要な教訓は単純である。ワークロード ID の信頼性は、それを検証するマシンの信頼性を超えることはできない。SPIFFE／SPIRE は長期間有効なシークレットによるリスクを軽減するが、ホストの root 権限が攻撃者に奪われた後には、ワークロード間の分離を維持することはできない。

インシデント対応計画に含める必要があるのは、認証情報のローテーション／セッションの確認／影響を受けたノードから発行された ID を受け入れたサービスの調査である。

開発環境や運用を学ぶ方向けに、Palo Alto Networks の Unit42 が発表したレポートを紹介する記事です。今回のテーマは Kubernetes と、SPIFFE (Secure Production Identity Framework for Everyone)／SPIRE (SPIFFE Runtime Environment) です。root 権限を奪われたノード上で cgroup データを変更されることにより、ローカルの SPIRE エージェントが他のワークロードの ID を悪意あるプロセスへ不正発行してしまう危険性が示されています。認証情報の不正取得／内部サービスへの横展開といった深刻な影響を防ぐため、特権コンテナの利用制限／ノードの保護強化／厳格なアクセス制御の適用など多層的な防御の実施が強く求められます。