🔒 鉄壁のセキュリティ Kubernetes RBAC: 見落としがちなベストプラクティス総まとめ

10月 23, 2026

—

こんにちは！Kubernetesクラスターを運用されていますか？もしそうなら、「セキュリティ」は決して見過ごせない最も重要なテーマでしょう。特に、複数のユーザーとワークロードが共存する環境では、誰が何を実行できるかを制御するRBAC（ロールベースアクセス制御）は、セキュリティの核心中の核心と言えます。🚀

しかし、RBAC設定、もしかして「とりあえずcluster-adminを与えればいいだろう」と安易に済ませていませんか？誤ったRBAC設定は、ハッカーにクラスター全体を明け渡す近道となり得ます。

今日は、クラスター運用者のために、安全で効率的なRBAC設計のための核心原則とベストプラクティス、そして私たちがうっかり見過ごしがちな権限昇格のリスクまで、徹底的に掘り下げて解説します！

1. 基本原則: これだけは必ず守ってください！ 🙏

安全なRBAC設計は、いくつかの基本原則から始まります。複雑に見えても、これらの原則をしっかり守れば、セキュリティレベルを大幅に向上させることができます。

最小権限の原則 (Least Privilege)

最も重要で基本的な原則です。ユーザーであれ、サービスアカウント(Service Account)であれ、自身の役割を果たすのに必要な最小限の権限のみを付与する必要があります。鍵束全体を渡すのではなく、必要な部屋の鍵だけを渡すのと同じです。

✅ ネームスペース(Namespace)単位で権限を付与してください。 クラスター全体に適用されるClusterRoleBindingではなく、特定のネームスペース内でのみ有効なRoleBindingを使用してください。これにより、特定のユーザーの活動範囲を明確に制限できます。
❌ ワイルドカード(“)権限は避けてください。 resources: [“”] のような設定は非常に危険です。現在クラスターに存在するすべてのリソースはもちろん、将来追加される新しいCRD(Custom Resource Definition)に対する権限まで自動的に付与してしまうからです。
👨‍✈️ cluster-adminロールは慎重に使用してください。 クラスター管理者だからといって、普段のすべての作業をcluster-adminアカウントで行うのは危険です。誤って重要なリソースを修正したり削除したりする可能性があるからです。低い権限のアカウントを使用し、必要な時だけimpersonate（偽装）機能を使用するのが安全です。
🚫 system:mastersグループにユーザーを追加しないでください！ このグループのメンバーは、すべてのRBAC権限チェックを回避するスーパーユーザーになります。一度付与された権限はRoleBindingを削除しても回収できないため、絶対に使用してはいけません。

特権トークン(Privileged Token)の配布最小化

強力な権限を持つサービスアカウントトークンがPodにマウントされることは、セキュリティ事故の出発点となり得ます。

強力な権限が必要なPodは特定のノードでのみ実行してください。 TaintsやNodeAffinityなどを使用して、重要なPodが信頼できない他のPodと一緒に実行されないように隔離してください。
サービスアカウントトークンの自動マウントを無効にしてください。 PodスペックにautomountServiceAccountToken: falseを設定すると、不要なトークンマウントを防ぐことができます。トークンが本当に必要なワークロードにのみ手動でマウントすることをお勧めします。

定期的なレビュー

RBAC設定は一度行えば終わりではありません。定期的に不要な権限がないか、削除されたユーザーの権限が残っていないかを確認する必要があります。攻撃者が削除されたユーザーと同じ名前のアカウントを作成すると、以前のユーザーのすべての権限を継承する可能性があるからです。

2. 知らないうちに権限昇格？知っておくべき危険ポイント 🚨

「この程度の権限なら大丈夫だろう」と思っていた設定が、深刻な権限昇格(Privilege Escalation)につながる可能性があります。以下の項目は特に注意深く確認する必要があります。

Secret list, watch権限の落とし穴

get権限がSecretの内容を読み取ることは誰もが知っています。しかし、listとwatch権限もSecretの内容をすべて公開できるという事実をご存知でしたか？kubectl get secrets -A -o yamlコマンドを実行すると、すべてのSecretの内容(dataフィールド)がそのまま出力されます。

ワークロード作成(create)権限の強力さ

PodやDeploymentのようなワークロードを作成できる権限は、想像以上に強力です。

該当ネームスペースのすべてのSecret、ConfigMapをPodにマウントして内容を窃取できます。
該当ネームスペースのどのようなサービスアカウントでもPodを実行させ、そのサービスアカウントの権限を獲得できます。
もしprivileged: true設定が可能であれば、ノード(Host)の権限を窃取することも可能です。

PersistentVolume作成権限

ユーザーがPersistentVolumeを直接作成できる場合、hostPathボリュームを作成してノードのファイルシステムにアクセスできます。これはコンテナ脱出およびノード掌握につながる非常に深刻なセキュリティ問題です。

危険な動詞(Verb) 4兄弟: escalate, bind, impersonate, proxy

escalate: 自身が持つ権限よりも高い権限を持つRoleを作成できるようにする、文字通り「権限昇格」の動詞です。
bind: 自身が持たない権限が含まれるRoleを他のユーザーにバインドできるようにします。つまり、他の人に自分よりも大きな権限を与えることができます。
impersonate: 他のユーザーを「偽装」して、そのユーザーのすべての権限を獲得できます。
nodes/proxy: ノードのプロキシサブソースへのアクセス権限がある場合、Kubelet APIを直接呼び出して、該当ノードのすべてのPodでコマンドを実行できます。これはRBACチェックと監査ログをすべて回避します。

その他の危険要素

CSR作成/承認: 新しいクライアント証明書を作成し、クラスターへの追加アクセス権限を得ることができます。
serviceaccounts/token作成: 既存のサービスアカウントのトークンを要求して、該当アカウントの権限を獲得できます。
Admission Webhook制御: クラスターに作成されるすべてのオブジェクトを読み取ったり改ざんしたりできる強力な権限です。
ネームスペースpatch権限: ネームスペースのラベルを修正してPod Security Admissionポリシーを回避したり、NetworkPolicyルールを変更したりできます。

3. サービス拒否(DoS)攻撃の危険 😫

ユーザーがクラスターにオブジェクトを作成する権限がある場合、意図的であるかどうかにかかわらず、非常に大きいか、または非常に多くの数のオブジェクトを作成してetcdを麻痺させることができます。これはクラスター全体の障害につながるサービス拒否攻撃となる可能性があります。

✅ 解決策: ResourceQuotasを使用して、ユーザーがネームスペース内で作成できるオブジェクトの数とサイズを制限してください。

まとめ

Kubernetes RBACは強力であると同時に複雑であり、小さなミスが大きなセキュリティ事故につながる可能性があります。今日見てきたベストプラクティスに基づいて、皆さんのクラスターRBAC設定をもう一度確認してみてください。

「最小権限の原則」を常に記憶し、危険な権限が不必要に付与されていないか定期的に確認する習慣が、安全なクラスターを構築する第一歩です。