Kubeflow Pipelinesで他テナントに不正実行、修正版あり
Kubeflow Pipelinesのマルチユーザー構成で、低権限の利用者が共有パイプラインへ不正な版を差し込み、他テナントの実行に紛れ込ませられます。2.18.0未満なら修正版へ更新し、API serverの公開範囲と定期実行の設定も見直してください。
急ぎ度: 早めに
CVSS v3は9.6で、修正版2.18.0が出ており、勧告に実機での再現結果も載っているため、早めの更新が妥当です。
関係があるか
複数のチームや利用者でKubeflow Pipelinesをマルチユーザーモードで共有している組織が対象です。とくにAPI serverへ認証プロキシを通さず直接届く環境と、最新版に追従する定期実行を使っている環境は優先して確認してください。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| Kubeflow Pipelines API server（イメージは ghcr.io/kubeflow/kfp-api-server） | 2.18.0未満（勧告では2.17.3以下）のマルチユーザーモード | 2.18.0 |
確かめ方
- 1クラスター内でkfp-api-serverのイメージタグを調べ、2.18.0未満かどうかを見ます。
- 2API serverの環境変数でMULTIUSERがtrueか、REQUIRE_NAMESPACE_FOR_PIPELINESが未設定のままかを確認します。同梱のマニフェストでは設定されていないため、手を加えていなければ既定のfalseです。
- 3API serverのHTTPエンドポイントが、認証プロキシを介さずに利用者やほかのネットワークから直接届くかを確認します。
- 4有効な定期実行のうち、特定の版に固定せず最新版に追従するものを洗い出します。
何が起きたか
Kubeflow Pipelinesのマルチユーザーモードで、API serverが共有パイプラインへのアップロードに対して書き込み権限を確認していませんでした。その結果、本来その権限を持たない利用者が共有パイプラインを作ったり、既存の共有パイプラインに自分の作った版を追加したりできます。差し込まれた版では、コンテナイメージ、コマンド、引数を置き換えられます。
原因はHTTPのアップロード用エンドポイント（POST /apis/v2beta1/pipelines/uploadとPOST /apis/v2beta1/pipelines/upload_version）にあります。認可の判定を行うcanUploadVersionedPipelineが、対象の名前空間が空のときSubjectAccessReviewを行わずに処理を通してしまいます。名前空間が空とは共有パイプラインのことで、呼び出し側が名前空間を省略した場合にもこの状態になります。REQUIRE_NAMESPACE_FOR_PIPELINESは既定でfalseのため、空の名前空間は入力検証でも弾かれません。
同じ書き込みを受けるgRPC側は、空の名前空間をシステム名前空間に読み替えて認可しており、共有パイプラインへの書き込みも認可が必要だという趣旨のコメントが付いています。ベンダーの勧告は、HTTP側のこの挙動を意図された仕様ではなく、認可の抜けとして扱っています。CWEはCWE-639とCWE-862です。
攻撃の流れ
-
1
書き込み要求
低権限のテナント、または直接届く未認証の呼び出し元が、名前空間を指定せずに共有パイプラインへの登録を要求します。
-
2
認可確認の省略
API serverは名前空間が空のとき権限確認を行わず、要求をそのまま受け付けます。
-
3
不正な版の登録
共有パイプラインを新規に作るか、既存の共有パイプラインにイメージやコマンドを差し替えた版を追加します。
-
4
他テナントで実行
最新版に追従する有効な定期実行が、差し込まれた版を他テナントの名前空間で実行します。
どう悪用されるか
悪用にはAPI serverのHTTPエンドポイントへ到達できる必要があります。ログイン済みの低権限テナントであれば、書き込み権限がなくても共有パイプラインへの登録が通ります。API serverに認証プロキシを通さず直接届く環境では、未認証の呼び出し元でも同じ抜け道を使えます。認証プロキシで守られている環境では、匿名のアクセスは通りません。利用者の操作は必要ありません。
被害が他テナントに及ぶのは、最新版に追従する未固定の定期実行が有効なときです。差し込まれた版は、その定期実行が動く他テナントの名前空間で、そのワークロードのサービスアカウントの権限で実行されます。特定の版に固定された実行や、仕様を埋め込んだ実行は、自動では差し替わりません。
CVSSの評価は、機密性と完全性への影響がいずれも高く、影響範囲が変わる（スコープ変更あり）となっています。実際にどこまで及ぶかは、実行されるワークロードのサービスアカウントに与えた権限しだいです。
今すぐやること
-
1
kfp-api-serverを2.18.0以降へ更新する
2.18.0では、共有パイプラインへのアップロードも、システム名前空間に対するpipelinesのcreate権限で認可します。まず稼働中のイメージタグを確認し、2.18.0未満なら更新計画を立ててください。
kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.spec.containers[*].image}{"\n"}{end}' | grep kfp-api-server -
2
API serverの公開範囲を確認する
認証プロキシを介さずに利用者や外部ネットワークから直接届く状態なら、未認証の呼び出しも通る可能性があります。更新までの間に、到達できる範囲を絞ってください。
-
3
共有パイプラインと定期実行を点検する
共有パイプラインの一覧で、作成者や登録時期に心当たりのないものと、追加された版を洗い出します。イメージ、コマンド、引数に不審な点がないかを見て、最新版に追従する定期実行がそれらを実行していないかも確認します。
-
4
不審な版があれば実行履歴を調べる
見つかった場合は、他テナントの名前空間での実行履歴と、実行に使われたサービスアカウントの権限を調べ、影響の範囲を判断してください。
すぐ更新できないとき
すぐに更新できないときは、API serverの前に認証プロキシを置き、直接届かないようネットワークで絞ります。これで匿名の呼び出しは防げますが、認証済みの低権限テナントによる書き込みは防げません。あわせて、重要な定期実行は特定の版に固定します。固定された実行は、新しく差し込まれた版に自動では切り替わりません。
背景
Kubeflow Pipelinesは、Kubernetes上で機械学習のワークフローを組み立てて実行する基盤です。マルチユーザーモードでは、利用者やチームごとに名前空間を分けて同じクラスターを共有します。パイプラインはコンテナとして動くため、実行時にはそのワークロードのサービスアカウントの権限が使われます。
この脆弱性の背景には、共有パイプラインの扱いがあります。共有パイプラインは特定の名前空間に属さず、クラスター全体で読めるように作られています。そのため読み取りの認可を省くのは仕様どおりです。一方で、書き込みはシステム名前空間に対して認可する決まりで、gRPC側はそのとおりに実装されていました。HTTPのアップロード用エンドポイントだけが、読み取り用の省略をそのまま書き込みに適用していたため、同じ操作でも入口によって認可の有無が分かれていました。
よくある質問
Q.認証プロキシで守っていれば、更新しなくてもよいですか。
Q.2.18.0に更新すれば、すでに差し込まれた版も消えますか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
Kubeflow Pipelines enables users to build and deploy portable, scalable machine learning workflows. Prior to 2.18.0, the multi-user HTTP endpoints POST /apis/v2beta1/pipelines/upload and POST /apis/v2beta1/pipelines/upload_version call canUploadVersionedPipeline, which returns without SubjectAccessReview when the target namespace is empty while REQUIRE_NAMESPACE_FOR_PIPELINES defaults to false. A low-privilege tenant can create shared pipelines or inject attacker-controlled versions into existing shared pipelines without the required write permission; if the API server is directly reachable without an authenticating proxy, an unauthenticated caller can exploit the same bypass, while deployments protected by such a proxy do not expose anonymous access. An enabled unpinned recurring run that follows the latest version can then execute the injected specification in another tenant's namespace under that workload's service account, while pinned or embedded-specification runs are not automatically substituted. This issue is fixed in version 2.18.0.
出典: CVE.org (CVE Program・cvelistV5) NVD