Kubernetes RBACの「穴」を埋める：特権昇格を許さない最小権限設計の極意
Kubernetesの運用において、最も頭を悩ませるのがRBAC（ロールベースアクセス制御）だ。「とりあえず動くように」とcluster-adminを付与したり、ワイルドカード()を多用したRole
結論から言えば、それは「鍵をかけずに玄関に札束を積んでいる」のと同じだ。攻撃者は、たった一つの脆弱なPodからクラスタ全体を掌握するルートを常に探している。今日は、現場で血を流しながら学んだ「RBACの防御と監査」の核心を解説する。
—
1. 攻撃者はどこを狙うのか？（PoCのリスク）
攻撃者がPodへの侵入に成功した際、最初に行うのはServiceAccountのトークンチェックだ。もしそのPodに紐づくServiceAccountがgetやlistの権限を持っていれば、攻撃者は即座に以下のコマンドを実行する。
Pod内のトークンを使って秘密情報を列挙
curl -v -H “Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)” \
https://kubernetes.default/api/v1/namespaces/default/secrets
さらに危険なのが「権限昇格」だ。もしcreateやpatch権限、特にbindやescalate権限を誤って付与していると、攻撃者は自分自身にcluster-adminを付与し、クラスタを完全に支配下に置く。
狙われる盲点：escalateとbind
escalate: 自身が持っていない権限を持つロールを作成・更新できる権限。bind: 権限を他のユーザーやサービスアカウントに付与できる権限。
これらを非特権ユーザーに渡すことは、自爆行為に等しい。
—
2. セキュアなRBAC設計の鉄則
「最小権限」とは、単に権限を絞るだけではない。「Podが必要とする最小限のAPIグループとリソースのみ」を許可するホワイトリスト形式で定義することだ。
実践：セキュアなRole設定例 (YAML)
以下は、特定のネームスペース内で「Podの読み取りのみ」を許可する、堅牢な設定サンプルだ。
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: production
rules:
- apiGroups: [“”] # コアAPIグループ
resources: [“pods”] # リソースをpodsに限定
verbs: [“get”, “list”, “watch”] # 変更系(create, update, delete)は許可しない
—
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
namespace: production
subjects:
- kind: ServiceAccount
name: web-app-sa # 特定のアプリ専用SAに紐付ける
namespace: production
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
—
3. 実務で役立つ「権限昇格」の監査方法
設計したルールが本当に安全かを確認するには、kubectl auth can-i コマンドを駆使する。運用チームは、CI/CDのパイプラインに以下のテストを組み込むべきだ。
監査コマンド例
特定のServiceAccountが、クラスタ全体に影響を与える権限を持っていないかを確認する。
web-app-sa が secrets を削除できるかテスト
kubectl auth can-i delete secrets –as=system:serviceaccount:production:web-app-sa
期待値は ‘no’ であるべき。’yes’ なら即座にポリシーを見直すこと。
もし、もっと高度な監査を自動化したいなら、Kubernetes Audit Logを有効化し、Falco等のランタイムセキュリティツールで不審なAPIコールを検知する仕組みを構築するのがプロの現場だ。
—
4. エンジニアへのアドバイス：インフラは「コード」で守れ
最後に、実務における防御のTipsを一つ。
開発者が独自にRBACを弄り回すと、必ず設定漏れが起きる。Kubernetesの権限管理は、TerraformやPulumiのような IaC (Infrastructure as Code) で一元管理し、権限変更には必ず「なぜその権限が必要なのか」のプルリクエストベースのレビューを必須にすること。
「動くこと」を優先してセキュリティを後回しにしても、インシデントが起きた後に失う信頼と工数は、その比ではない。
もしあなたが現場のリーダーなら、まず自チームのClusterRoleBindingを全部叩き出し、cluster-adminが誰に付与されているかを確認することから始めてほしい。意外なほど「不要な権限」が放置されているはずだ。
セキュリティは終わりなき旅だが、まずはこの「最小権限の徹底」という城壁を築くことから始めよう。次のインシデントを未然に防ぐのは、他ならぬ君のその一行のコードだ。
コメント