Console operatorでテナント越えの権限昇格の恐れ
Strimzi と連携する Console の operator に、Console リソースを作れるテナントが強い権限を持つ Pod を自分で用意でき、他テナントの Kafka 関連リソースまで読み書きされる弱点が見つかりました。CVSS は 9.9 で、複数のチームや顧客で Kubernetes クラスターを共有している組織が主な対象です。修正版や悪用の有無は公表情報から確認できないため、まず自社の該当有無と権限設定を点検し、ベンダーの告知を確認してください。
急ぎ度: 早めに
CVSS 9.9 で認証済みの低権限ユーザーから悪用できますが、実際の悪用の確認は公表されておらず、悪用には Console リソースの作成権限が必要です。
関係があるか
Strimzi で Kafka を運用する Kubernetes クラスターに Console の operator を導入し、複数のテナント(チーム、部門、顧客)に Console リソースの作成権限を渡している環境が影響を受けます。クラスターを管理者だけが使っている環境では、リスクはかなり下がります。
| 製品 | 影響を受ける版 | 直った版 |
|---|---|---|
| Strimzi と連携する Console の operator(Console カスタムリソースを扱うもの) | 影響を受ける版は公表されていません | 修正版は現時点で明らかになっていません。Red Hat の告知と GitHub のアドバイザリで確認してください |
確かめ方
- 1クラスターに Console のカスタムリソース定義があるかを確かめます。
kubectl api-resources | grep -i console - 2Console リソースの作成権限を誰が持っているかを確かめます。管理者以外のテナントのユーザーやサービスアカウントで
kubectl auth can-i create consoles -n <namespace> --as=<ユーザー名>を実行し、yes になるかを見ます。 - 3既存の Console リソースの container image の指定が、自社で承認したイメージだけになっているかを確認します。見覚えのない image があれば調査してください。
- 4operator が配置する Pod のサービスアカウントに、ClusterRoleBinding でどんな権限が付いているかを
kubectl get clusterrolebindings -o wideなどで確認します。
何が起きたか
Kubernetes 上で Strimzi(Kafka を管理する仕組み)と一緒に使う Console の operator に、権限の扱いの誤りが見つかりました。Console リソースを作成できる利用者が、起動するコンテナのイメージを自由に指定できてしまいます。operator はそのイメージを、強い権限を持つ Pod として動かします。結果として、本来は管理者に限られるはずの操作が、一般のテナントから行えるようになります。
具体的には、Console リソースの spec.containers.api.spec.image に任意のイメージを指定できます。operator が起動する Pod のサービスアカウントは、ClusterRoleBinding によって次の権限を持っています。
- Strimzi の全 CRD(KafkaUser を含む)に対するクラスター全体の get/list/watch
- Kafka と KafkaRebalance に対する patch
- cluster-monitoring-view
攻撃者が用意したコードは、Pod に渡されたサービスアカウントのトークンを読み取り、この権限を使えます。
分類は CWE-269(不適切な権限管理)で、深刻度は CVSS v3.1 で 9.9 の critical です。攻撃元はネットワーク経由、必要な権限は低、利用者の操作は不要で、影響範囲が脆弱なコンポーネントの外に及ぶ評価になっています。
攻撃の流れ
-
1
リソース作成
Console リソースの作成権限を持つテナントのユーザーが、任意のイメージを指定した Console リソースを作ります。
-
2
Pod の展開
operator が指定されたイメージを、強い権限を持つサービスアカウントの Pod として展開します。
-
3
トークン取得
Pod 内のコードが、渡されたサービスアカウントのトークンを読み取ります。
-
4
権限の行使
トークンを使い、他テナントを含む Strimzi 関連リソースを読み取り、Kafka などを変更します。
どう悪用されるか
悪用には、Kubernetes クラスターの認証済みユーザーで、Console リソースの作成権限を持っていることが前提です。管理者権限は不要で、被害者側の操作も必要ありません。ネットワーク経由でクラスターの API に到達できれば足りるため、共有クラスターでは低い権限から高い権限へ到達できる経路になります。
悪用された場合、他テナントの KafkaUser などの Strimzi リソースが読み取られ、Kafka や KafkaRebalance が変更されるおそれがあります。CVSS では機密性と完全性への影響が高、可用性への影響が低と評価されています。メッセージ基盤の設定が書き換えられると、他のチームや顧客のサービスにも波及しかねません。
今すぐやること
-
1
利用の有無と該当範囲を把握する
Strimzi と Console の operator を導入しているクラスターを洗い出し、Console リソースの作成権限がどのテナントに渡っているかを一覧にします。
kubectl api-resources | grep -i console -
2
作成権限を最小限に絞る
Console リソースの create を、信頼できる管理者やプラットフォームチームに限定します。一般のテナントに付与している Role や ClusterRole を見直してください。
kubectl auth can-i create consoles -n <namespace> --as=<ユーザー名> -
3
既存の Console リソースを点検する
各 Console リソースの container image が承認済みのものかを確認します。不明なイメージがある場合は、Pod の実行履歴と Kubernetes の監査ログを調べ、サービスアカウントの権限が使われた形跡がないかを確認します。
-
4
ベンダーの告知を確認して更新する
Red Hat の告知ページと GitHub のアドバイザリで、影響を受ける版と修正版の公表を確認し、公表され次第、検証環境で試したうえで更新します。
すぐ更新できないとき
修正版を当てられない間は、Console リソースの作成権限を管理者に限ることが最も確実な対策です。あわせて、Kyverno、OPA Gatekeeper、ValidatingAdmissionPolicy などの admission 制御で、Console リソースに指定できる image を自社で承認したレジストリやイメージに限定する方法があります。operator のサービスアカウントの権限を削る方法は、operator が動かなくなるおそれがあるため、ベンダーの案内を確認してから行ってください。
背景
Kubernetes の operator は、利用者が作ったカスタムリソースの内容を読み取り、それに合わせて Pod などを自動で作る仕組みです。operator 自身は、その作業のために広い権限を持つのが普通です。Strimzi は Kafka を Kubernetes 上で運用するための代表的な operator で、Console は Kafka の状態を画面で確認する管理用の部品として使われます。
今回のように、権限の低い利用者の依頼を、権限の高い operator が内容を十分に絞らないまま実行してしまう問題は、Kubernetes の operator に限らず、権限管理の典型的な落とし穴です。窓口の担当者が、依頼書の内容どおりに自分の持つ合鍵で部屋を開けてしまうようなものです。共有クラスターでは、誰がどのリソースを作れるかと、operator が代理で何をできるかを合わせて見直す必要があります。
よくある質問
Q.クラスターを自社の管理者しか使っていません。対応は必要ですか。
Q.すでに攻撃を受けたかどうかは分かりますか。
Q.実際に攻撃で使われていますか。
まだ分かっていないこと
- 影響を受ける版と修正版の具体的な番号は、現時点で明らかになっていません。
- 実際の攻撃での悪用や、攻撃手順の公開の有無は公表されていません。
- operator のサービスアカウントの権限を、修正によってどう絞るのかは明らかになっていません。
この記事は、取得元の公開情報をもとに生成 AI で作成しています。誤りを含むことがあります。対応を決める前に、下の原文と参照先を確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
A Kubernetes tenant with create permission on Console custom resources can set spec.containers.api.spec.image to an arbitrary container image. The operator deploys this image into a pod whose ServiceAccount is bound via ClusterRoleBinding to a ClusterRole granting cluster-wide get/list/watch on all Strimzi CRDs (including KafkaUsers), patch on Kafkas/KafkaRebalances, and cluster-monitoring-view. The attacker's code reads the projected SA token and gains cross-tenant Strimzi control-plane read+write access.
出典: NIST National Vulnerability Database NVD GitHub Advisory
参照URL
- web secalert@redhat.com
- web secalert@redhat.com
- web nvd.nist.gov
- web github.com