本文へスキップ
MameTechNews
バックエンド

Portainer、一般権限でクラスタ内の任意Podを実行できる欠陥

## POINTS

  • 標準ロールのユーザーが重複クエリで、Agentのcluster-adminとして任意Podを実行できる。
  • 修正済みは2.39.6と2.45.0。2.40〜2.44に個別修正はなく、2.45.0へ移す。
  • ローカル接続のKubernetesは対象外。更新まではシェルの無効化とexec監査が暫定策になる。

Portainerは10月22日、Kubernetes環境のブラウザ版kubectlシェルに関するアドバイザリを公開した。ユーザーがシェルを開くと、サーバは短命のシェルPodを作り、WebSocketの向き先をそのPodへ書き換えてAgentへ渡す。書き換えは呼び出し元のクエリへnamespace、podName、containerName、commandを足すだけで、置き換えていなかった。Agentは同名パラメータの最初の値を使うため、呼び出し側が先に置いた値が優先され、自分のシェルPod以外を実行できた。

Agent管理とEdge Agent管理では、実行主体がAgent自身のサービスアカウントになる。公開マニフェストはこのアカウントをcluster-adminに紐づける。標準ロールでその環境へ入れる認証済みユーザーなら、Portainer管理者権限もKubernetesの資格情報も、被害者の操作も要らない。ローカル接続で管理する環境は、Podの位置を引数で渡すためこの経路の対象外だ。GitHub上の深刻度はModerate、CVSSは6.5だが、影響先はPortainer自身ではなく管理下のクラスタ全体だとアドバイザリは書いている。

2.39系は2.39.0以降が影響を受け、2.39.6で直っている。2.45.0にも修正がある。2.40から2.44に個別の修正版はなく、2.45.0へ移す。2.39.0より前はサポート終了で修正はない。2.39.6は8月13日、2.45.0は8月27日に出ており、今回の公開はそれより後だ。両エディションに同じ修正が入る。

すぐ更新できない場合、Business Editionは管理者以外のkubectlシェルを止められる。Community Editionに同じスイッチはなく、Agent管理の環境を管理者だけに絞る。Agentのサービスアカウントによるpods/execのうち、正規のシェルと対応しないものを監査し、読まれた可能性のあるSecretをローテーションする。