1. 導入：なぜRBACが必要なのか？
Kubernetes（K8s）で開発を進める際、「開発者に全権限を渡すのは怖い」「CI/CDツールにはデプロイ権限だけ持たせたい」と考えたことはありませんか？RBAC（Role-Based Access Control：役割ベースのアクセス制御）は、まさにその課題を解決する仕組みです。特定のユーザーやサービスに対して、必要な操作だけを許可することで、誤操作によるシステム破壊やセキュリティリスクを最小限に抑えることができます。
2. 基礎知識：RBACを構成する3つの要素
RBACを理解するには、以下の3つの要素をセットで覚えるのが近道です。
・Role（役割）：「何ができるか」を定義します。例えば、「Podの閲覧のみ」「Deploymentの更新のみ」といった許可リストです。
・Subject（対象）：「誰が」を指します。ユーザーや、プログラムが操作を行うための「ServiceAccount」などが該当します。
・RoleBinding（紐付け）：「誰」に「どの役割」を与えるかを結びつける接着剤の役割です。
※Namespace（名前空間）ごとに適用するものを「Role」、クラスタ全体に適用するものを「ClusterRole」と呼びます。
3. 実装：最小権限を実現する手順
実際に「特定のNamespace内のPod情報を閲覧するだけ」の権限を作成し、特定のServiceAccountに割り当てる手順を解説します。
1. 権限（Role）を作成する。
2. 実行主体（ServiceAccount）を作成する。
3. RoleBindingで両者を紐付ける。
4. サンプルプログラム
以下のマニフェストを `rbac-sample.yaml` として保存し、`kubectl apply -f rbac-sample.yaml` で適用してください。
1. 閲覧専用のロール定義
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: default
rules:
- apiGroups: [“”] # コアAPIグループを指定
resources: [“pods”] # Podリソースを対象に
verbs: [“get”, “list”] # 閲覧のみ許可
—
2. 権限を行使するサービスアカウント
apiVersion: v1
kind: ServiceAccount
metadata:
name: ci-cd-user
namespace: default
—
3. ロールとサービスアカウントの紐付け
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
namespace: default
subjects:
- kind: ServiceAccount
name: ci-cd-user
namespace: default
roleRef:
kind: Role
name: pod-reader # 上記で作成したRoleを指定
apiGroup: rbac.authorization.k8s.io
5. 応用・注意点：現場で陥りやすい罠
現場で運用する際に特に注意すべき点は以下の通りです。
・「とりあえずadmin」の禁止：テスト中だからといって `cluster-admin` 権限を安易に付与するのは避けましょう。一度付与すると、そのアカウントが乗っ取られた場合にクラスタ全体が危険にさらされます。
・検証方法：権限が正しく設定されたかは、`kubectl auth can-i` コマンドで確認できます。例えば、`kubectl auth can-i get pods –as=system:serviceaccount:default:ci-cd-user` と実行すれば、そのアカウントがPodを取得できるか即座に判定可能です。
・Namespaceの意識：Roleを使う場合は名前空間が一致しているか必ず確認してください。異なる名前空間のリソースを操作させる場合は、ClusterRoleとClusterRoleBindingが必要になります。
まずは「閲覧のみ」の権限設定から試し、徐々に必要な範囲へ権限を広げていく「最小権限の原則」を徹底しましょう。
コメント