Kubernetesにおけるアクセス制御の仕組み「RBAC（Role-Based Access Control）」について、基本的な流れとポイントを簡潔にまとめました。
📌 基本の流れ
RBACを使う場合、以下の順序で設定を行います：
- Role または ClusterRole の作成
- 対応する RoleBinding または ClusterRoleBinding の作成
🧩 RoleとBindingの違い
| リソース | 適用範囲 |
|---|---|
Role |
特定のNamespace内に限定されるアクセス制御 |
ClusterRole |
クラスタ全体に適用されるアクセス制御 |
RoleBinding |
RoleとUser/Group/ServiceAccountをNamespace内で関連付ける |
ClusterRoleBinding |
ClusterRoleをクラスタ全体でUser/Group/ServiceAccountに関連付ける |
👥 subjects.kindの種類
RoleBindingやClusterRoleBindingのsubjects.kindには以下の3つがあります：
-
User: 個別のユーザー -
Group: ユーザーのグループ -
ServiceAccount: Podなどに割り当てるサービスアカウント
🛠️ ServiceAccountとPodの関連付け
-
PodにserviceAccountNameを指定することで、PodはそのServiceAccountの権限で動作します。 -
ServiceAccountをRoleやClusterRoleとバインディングすることで、Podのアクセス権限を制御できます。
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
serviceAccountName: example-sa
containers:
- name: app
image: nginx
✅ まとめ
RBACの基本はシンプルです。
- まず**権限（Role/ClusterRole）**を定義し、
- 次に**それを誰に適用するか（RoleBinding/ClusterRoleBinding）**を決める。
特にServiceAccountと組み合わせれば、Pod単位で細かい権限制御が可能になります。
セキュリティ強化のためにも、ぜひ活用してみましょう！