Kubernetesの「神」を殺す：RBAC過剰付与が招くクラスタ崩壊の解剖学
KubernetesにおけるRBAC（Role-Based Access Control）の設計を、「とりあえず cluster-admin を付与しておこう」という安易な妥協で済ませているなら、それは自らクラスタの鍵を攻撃者に手渡しているに等しい。
多くのエンジニアは「Kubernetesはコンテナの集まり」だと認識しているが、セキュリティの深淵から見れば、K8sは「APIサーバーという名の巨大な攻撃対象領域（アタックサーフェス）」だ。一度APIサーバーの権限を奪取されれば、コンテナのランタイム隔離など無力に等しい。今日は、実戦で最も被害が深刻化する「RBACの特権昇格」に焦点を当て、防衛の最前線を語ろう。
—
1. ClusterRoleの罠：ワイルドカードの代償
ClusterRole はクラスタ全体に影響を及ぼす。ここに resources: ["*"] や verbs: ["*"] を記述することは、攻撃者に「クラスタの全ステートを操作する特権」を与えることに他ならない。
攻撃者は、特権を持つPodに侵入した後、/var/run/secrets/kubernetes.io/serviceaccount/token を奪取する。もしそのトークンが広範囲な ClusterRole を持っていれば、彼は即座にクラスタ内の全Secretをダンプし、クラウドの認証情報やDBの接続文字列を抜き取るだろう。
監査すべき「殺し」の権限
特権昇格のトリガーとなるのは、以下の3つのキーワードだ。
bind:RoleBindingを作成・更新する権限。自身より上位の権限を付与することで、実質的な特権昇格が可能。escalate:Roleの権限を拡張する権限。自身が持っていない権限を付与したRoleを作成できる。impersonate: 他のユーザーやサービスアカウントになりすます権限。これが最も危険な「ステルス権限」だ。
—
2. 実践的ガードレール：RBACの最小権限設計
「何ができるか」ではなく「何をすべきでないか」から逆算する。以下は、開発者がNamespace内でのみ動作し、かつ不必要な操作を排除したロール定義のサンプルだ。
# 最小権限を適用したRoleの定義例
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: limited-app-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"] # 特定リソースのみに絞る
verbs: ["get", "list", "watch"] # 書き込み・削除権限は付与しない
# 以下の権限は決して含めてはならない
# - apiGroups: ["rbac.authorization.k8s.io"]
# resources: ["roles", "rolebindings"]
# verbs: ["bind", "escalate"]監査コマンドによる現状把握
現在のクラスタに「誰が危険な権限を持っているか」を確認するには、以下のコマンドが有用だ。
# 特権昇格可能なユーザー・SAを特定する（kubectl-who-canプラグインを推奨）
kubectl who-can escalate clusterrole
kubectl who-can bind clusterrole—
3. 次世代の脅威：AIとプロンプト、そしてランタイムの境界
現代のセキュリティアーキテクトは、単にRBACを縛るだけでなく、その先の「AIエージェントによるクラスタ操作」や「耐量子暗号への移行」も見据える必要がある。
LLMによる操作のガードレール
もしクラスタ管理をAIに委譲（オートメーション）しているなら、Admission Controller での制限は必須だ。ValidatingWebhookConfiguration を使い、AIが生成した kubectl コマンドやAPIリクエストが、特定のパターン（例えば secrets への無差別なアクセス）を含んでいないか検閲する「ガードレール」を構築せよ。
プロトコルレベルの視点
K8s APIサーバーとノード（Kubelet）間の通信は TLS で保護されているが、将来的な「量子計算機による暗号解読（Shorのアルゴリズム）」を見据えれば、現在の ECDSA や RSA ベースの通信は脆弱だ。今後は Kyber 等の耐量子アルゴリズム（PQC）を考慮したサービスメッシュ（Istio/Linkerd）の構成検討が、大規模インフラの寿命を左右するだろう。
—
結び：インシデントハンドリングの極意
私がこれまで見てきた大規模な侵害のほとんどは、技術的なゼロデイ脆弱性ではなく、「管理上の怠慢」から始まっている。ClusterRole を安易に割り振ることは、鍵をかけ忘れた金庫を街中に放置するのと同じだ。
1. デフォルトの system:serviceaccount の権限を徹底的に削れ。
2. Namespace を超えた権限付与は、必ず人手によるピアレビューを義務付けろ。
3. Audit Log を常に監視し、escalate 権限が使用された瞬間を検知できるSIEM連携を構築せよ。
セキュリティは静的な状態ではない。攻撃者は常に「設計上の盲点」を探している。君たちが設計したそのRBACルールは、本当に「必要最小限」だろうか？ 一度立ち止まり、その定義ファイルを再確認してほしい。それが、君のクラスタを真の要塞へと昇華させる第一歩となる。
コメント