クラスターの定型的な管理作業を自動化するために設計されたKubernetesオペレーターは、サービスアカウントに運用上必要な範囲を大きく超える権限が与えられると、影響の大きいバックドアになりかねません。
Palo Alto NetworksのUnit 42は、オープンソースの分析ツール「OperTraitor」を公開しました。このツールはKubernetesオペレーターのRBACマニフェストを調べ、付与された権限を公開されている機能と突き合わせたうえで、1〜10のリスクスコアを割り当てます。
自律的な意思決定とKubernetes APIへの特権アクセスを組み合わせたエージェント型AIオペレーターを導入する組織が増えるにつれ、リスクは高まっています。
このツールは、ローカルにデプロイされたオペレーターの構成や、OperatorHubカタログの構成を取り込めます。オペレーターが攻撃者の侵入口になる前に、過剰な権限を特定するのに役立ちます。
Kubernetesオペレーターは、カスタムリソース定義（CRD）と、クラスターの実際の状態を望ましい状態へ継続的に調整するコントローラーで構成されます。この役割を果たすため、コントローラーは、RoleまたはClusterRoleにバインドされたKubernetesサービスアカウントの下で動作します。
この非人間アイデンティティが、侵害された場合の被害範囲を決めます。攻撃者が脆弱な依存関係、悪意あるイメージの更新、サプライチェーン侵害、公開された管理インターフェースなどを通じてオペレーターを悪用すると、そのAPI権限を引き継ぎます。
Secretの読み取り、RBACリソースの変更、ワークロードの作成といった権限がクラスター全体に及んでいると、当初は限定的だった侵入がクラスター全体の乗っ取りに発展しかねません。
Unit 42によると、開発者はデプロイの失敗を避け、柔軟なワークフローに対応するために、ワイルドカードを使ったRBACルールを多用しがちです。しかし、広範な権限は、信頼されたオペレーターを知らないうちに永続的なバックドアへ変えてしまう可能性があります。
同社の調査では、評価したオペレーターの5％超が過剰な権限を要求していました。その中には、cluster-admin相当のアクセスを可能にしうる経路も含まれていました。
決定論的な自動化から、LLMを活用したエージェント型オペレーターへと移行することで、脅威モデルも変わります。従来のオペレーターは、あらかじめ定義された調整ロジックを実行するだけでした。
AIを強化したオペレーターは、文脈を解釈し、ツールを呼び出し、外部サービスと連携し、修復アクションを動的に実行できます。
広範なクラスター権限に加え、LLMとの接続やModel Context Protocolのブリッジを備えたオペレーターは、機密性の高いクラスターデータを外部のエージェントに晒したり、そのエージェントが重大な変更を加えたりする事態を招く恐れがあります。
クラスター内で動作する完全なエージェントランタイムにも、同様の懸念があります。基盤となるサービスアカウントがSecretの列挙、特権Podの作成、ClusterRoleBindingの変更を行える場合、エージェントの予測不能な挙動は特に危険です。
問題の核心は、引き続きアイデンティティガバナンスにあります。エージェント機能が過剰なRBAC権限を生み出すわけではありません。ただ、その権限の悪用を、より速く、より大規模に、より予測しにくくします。
OperTraitorは、IBMのTurbonomic Prometurboエージェントで、クラスター全体に及ぶ過剰なSecretアクセスを特定しました。対象のサービスアカウントは、本来想定された名前空間に制限されず、クラスター全体のSecretに対してget、list、watchの操作を実行できました。
IBMはCVE-2026-6389にCVSSスコア8.8を割り当てました。この脆弱性はPrometurboのバージョン8.16.0から8.17.6に影響します。オペレーターやそのサービスアカウントを侵害した攻撃者が、認証情報の窃取や権限昇格を行い、クラスター全体を侵害する可能性があります。IBMはバージョン8.18.0でこの問題を修正しました。
セキュリティチームは、各オペレーターのサービスアカウントを、本番環境の特権アイデンティティとして扱うべきです。デプロイ前にベンダーのマニフェストを確認してください。特に、ClusterRole、ClusterRoleBinding、ワイルドカードのverb、Secretへのアクセス、RBACオブジェクトの作成や変更の権限に注意が必要です。
オペレーターは、可能な限り名前空間スコープにとどめるべきです。クラスタースコープの権限は、必要性を明確にしたうえで最小限に抑え、定期的に見直す必要があります。
また、OperatorHubやOLMの掲載情報が最新だと思い込まないようにしてください。サポート対象のバージョンについては、ベンダーが保守しているHelmチャート、リポジトリ、リリースドキュメントで確認することを推奨します。
最後に、Kubernetes監査ログを使ってサービスアカウントの想定される挙動を把握し、異常を検知する必要があります。たとえば、オペレーターが無関係な名前空間のSecretを読み取ったり、通常とは異なるインフラからAPIサーバーにアクセスしたりする挙動です。
AI対応のオペレーターでは、アウトバウンドのネットワークアクセスを制限することも重要です。あわせて、モデル駆動のコンポーネントが利用できるデータ、ツール、権限を厳格に管理してください。
16,000以上のSOCチームがANY.RUNを活用し、脅威調査を効率化して手作業を削減しています。 チームでの利用を検討する
翻訳元: https://cyberpress.org/kubernetes-operators-with-excessive-privileges/
