レッスン3: RBAC & 認可

1. RBACモデル

RBACの4つのリソース:

NamespaceスコープRBAC:
  Role ──────────► 特定Namespaceの権限を定義
  RoleBinding ──► UserまたはSAをRoleにバインド

クラスタスコープRBAC:
  ClusterRole ────► クラスタ全体の権限を定義
  ClusterRoleBinding ► UserまたはSAをClusterRoleにバインド

2. Role & ClusterRole

# Namespace内の権限（Role）
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader
rules:
- apiGroups: [""]         # core API group
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

---
# クラスタ全体の権限（ClusterRole）
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["persistentvolumes"]
  verbs: ["get", "list"]

3. RoleBinding & ClusterRoleBinding

# UserをRoleにバインド
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

---
# SAをClusterRoleにバインド
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-nodes-global
subjects:
- kind: ServiceAccount
  name: monitoring-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

試験のポイント：kubectl auth can-iはRBACデバッグの強力なツールです。kubectl auth can-i get pods --as jane -n devで特定ユーザーの権限を確認できます。

4. ServiceAccount

# SAの作成
kubectl create serviceaccount monitoring-sa -n monitoring

# SAトークンの確認（v1.24+ではTokenRequest APIを使用）
kubectl create token monitoring-sa -n monitoring

# PodにSAを指定
apiVersion: v1
kind: Pod
metadata:
  name: monitor-pod
spec:
  serviceAccountName: monitoring-sa
  containers:
  - name: app
    image: monitor:latest

5. RBACデバッグ

# 権限チェック
kubectl auth can-i create deployments --as jane -n dev
kubectl auth can-i delete nodes --as system:serviceaccount:monitoring:monitoring-sa

# 全権限の確認
kubectl auth can-i --list --as jane -n dev

# RBACリソースの確認
kubectl get roles,rolebindings -n dev
kubectl get clusterroles,clusterrolebindings | grep node-reader
kubectl describe rolebinding read-pods -n dev

6. チートシート

タスク	コマンド
Role作成	kubectl create role NAME --verb=get,list --resource=pods -n NS
RoleBinding作成	kubectl create rolebinding NAME --role=ROLE --user=USER -n NS
ClusterRole作成	kubectl create clusterrole NAME --verb=get,list --resource=nodes
権限チェック	kubectl auth can-i VERB RESOURCE --as USER -n NS
SA作成	kubectl create sa NAME -n NS

7. 練習問題

Q1：ユーザーjohnがdev namespaceでPodの作成はできるが、default namespaceではできない場合、どのRBACリソースの組み合わせが使われていますか？

• A) ClusterRole + ClusterRoleBinding
• B) Role（dev ns内）+ RoleBinding（dev ns内） ✓
• C) ClusterRole + RoleBinding（dev ns内）
• D) Role（default ns内）+ RoleBinding

解説：特定のNamespaceに限定した権限にはRoleとRoleBindingを使用します。選択肢Cも技術的に正しいですが、Bが最も直接的な回答です。ClusterRoleをRoleBindingで使用すると、そのNamespace内でのみClusterRoleの権限が適用されます。

Q2：kubectl auth can-i delete pods --as system:serviceaccount:app:mysa -n appの結果が"no"の場合、どのような権限を付与する必要がありますか？

• A) app NamespaceにPod deleteのRoleとRoleBindingを作成し、ServiceAccount mysaにバインド ✓
• B) kube-system Namespaceでadminのcluster-admin権限を付与
• C) ServiceAccountを削除して再作成
• D) kubeletを再起動

解説：ServiceAccountにPod削除権限を付与するには、verb: deleteのRoleを作成し、RoleBindingでSAにバインドします。kubectl create role pod-deleter --verb=delete --resource=pods -n app、kubectl create rolebinding pod-deleter-binding --role=pod-deleter --serviceaccount=app:mysa -n appで実行できます。

Q3：ClusterRoleBindingとRoleBindingの違いは？

• A) ClusterRoleBindingのみがServiceAccountをサポートする
• B) ClusterRoleBindingはクラスタ全体で有効、RoleBindingは特定のNamespace内でのみ有効 ✓
• C) RoleBindingはClusterRoleを参照できない
• D) ClusterRoleBindingはRoleを参照できる

解説：ClusterRoleBindingはクラスタ全体のスコープ、RoleBindingはNamespaceスコープです。RoleBindingはClusterRoleを参照できます（その場合、ClusterRoleの権限はそのNamespace内に限定されます）。