Kubernetes RBACの深淵：権限昇格を許さない「最小権限」の設計思想
KubernetesのRBACは、多くのエンジニアにとって「設定すれば終わり」のチェックリストに過ぎない。しかし、現場でインシデント対応を繰り返す我々から見れば、RBACの不備は、攻撃者がクラスタを掌握するための「特急券」に他ならない。
特に、ClusterRoleを安易に使い、ワイルドカード(“)を付与したサービスアカウントが、Podのセキュリティコンテキストをすり抜けてホストノードにまで干渉する事例は後を絶たない。本稿では、表面的な設定ガイドを超え、攻撃者の視点から見た「RBACの脆弱性」と、それを封じ込めるためのアーキテクチャ設計について論じる。
—
1. なぜ「権限昇格」は起きるのか：攻撃者の視点
攻撃者がKubernetesクラスタに侵入した際、まず確認するのはkubectl auth can-i --listである。ここでpatchやcreate権限がPodやSecretに対して与えられていれば、勝負は決したも同然だ。
攻撃シナリオ：トークンの抽出と昇格
攻撃者が狙うのは、過剰な権限を持つPodからマウントされているServiceAccountのトークンだ。これを用いてAPIサーバーを叩き、より権限の強いPodを起動してホストのプロセス空間にアクセスしたり、ClusterRoleBindingを操作して自らの権限を恒久化させる。
この根本原因は、「リソース」と「アクション」を紐付けるRBACの構造が、実行時のコンテキスト（どのノードで動いているか、どのネットワーク空間にいるか）を考慮していないことにある。
—
2. 最小権限の鉄則：RoleとBindingの厳密な分離
ClusterRoleは強力だが、その影響範囲はクラスタ全体に及ぶ。namespaceを跨ぐ必要がない限り、例外なくRoleとRoleBindingを使用すべきだ。
以下は、特定のPodに対して「Podのステータス参照」のみを許可し、他のいかなる操作も拒否する最小権限の定義例である。
最小権限のRole定義
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: pod-reader-role
rules:
- apiGroups: [“”]
resources: [“pods”]
verbs: [“get”, “list”] # 最小限の動作のみ許可（deleteやpatchは排除）
—
特定のServiceAccountへのバインディング
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: pod-reader-binding
namespace: production
subjects:
- kind: ServiceAccount
name: app-runner-sa # アプリ用SA
namespace: production
roleRef:
kind: Role
name: pod-reader-role
apiGroup: rbac.authorization.k8s.io
ここで重要なのは、verbsの選定だ。listはノード上のすべてのPod情報を抽出できるため、状況によっては慎重に扱う必要がある。さらに、特定のPodリソースに対してはresourceNamesフィールドを指定し、操作可能な対象をさらに絞り込むのが「防衛の極意」だ。
—
3. 権限昇格リスクの監査と自動検知
手動の監査は限界がある。KubernetesのRBAC設定は、静的なYAML解析だけでなく、APIサーバーの監査ログ（Audit Logs）との照合が必要だ。
監査すべき3つのポイント
1. bind権限の監視: rbac.authorization.k8s.ioグループのclusterrolebindingsに対してcreateやupdateを行う権限を誰が持っているか。
2. impersonate権限の排除: usersやserviceaccountsを偽装する権限は、管理者以外には絶対に与えてはならない。
3. 匿名アクセス: system:anonymousがクラスタ内で何らかの権限を持っていないか。
これらの監査には、OPA (Open Policy Agent) や Kyverno を導入し、CI/CDパイプラインに「RBAC構成のバリデーション」を組み込むことが不可欠だ。
Kyvernoによるポリシー例：過剰権限の禁止
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-clusterrole-wildcards
spec:
validationFailureAction: Enforce
rules:
- name: forbid-wildcard-verbs
match:
resources:
kinds: [“ClusterRole”]
validate:
message: “ClusterRoleでのワイルドカード利用は禁止されています。”
pattern:
rules:
- verbs: [“!”] # ” を禁止する
—
4. チーフホワイトハッカーからの提言：境界の再定義
最後に、より高いレイヤの防衛について述べる。今後、耐量子暗号（PQC）の普及や、LLMによるインフラ自動化が加速するにつれ、RBACだけで防御する時代は終わる。
我々は今、「ゼロトラスト・ネットワーキング」と「RBAC」を統合するステージにいる。Pod間通信をmTLSで制御し、APIサーバーへのアクセスにはIDプロバイダ（OIDC）を介した動的な短命トークンを利用する。
「権限は付与するものではなく、必要になった瞬間に生成し、用が済めば即座に無効化するもの」。この哲学をKubernetesインフラに実装できた時、初めてあなたのクラスタは堅牢と言える。
設定ファイルの一つひとつに「なぜこの権限が必要なのか？」という問いを立てろ。その疑念こそが、サイバー攻撃を未然に防ぐ最強の盾となる。
コメント