KubernetesでのRBAC拡張をシンプルに：Aggregate ClusterRoleの活用方法

Kubernetesを運用していると、権限管理（RBAC: Role-Based Access Control）は避けて通れないテーマです。ClusterRoleを使うことで、クラスター全体にわたるリソース操作権限をユーザーやServiceAccountに割り当てられます。しかし、クラスターは日々進化し、新たなAPIやカスタムリソース（CRD）が追加されていくと、既存のRoleやClusterRoleを手動で更新するのは骨が折れる作業です。

そんなときに役立つのがAggregate ClusterRoleの仕組みです。本記事では、Aggregate ClusterRoleが提供するメリットや基本的な考え方、そして実際のサンプルYAMLを示しながら、その使い方を解説します。

## Aggregate ClusterRoleとは？

Aggregate ClusterRoleは、Kubernetes 1.9以降で導入された機能で、指定したアノテーションを介して、あるClusterRoleを自動的に別のClusterRoleへ集約（結合）させる仕組みです。

これにより、以下のようなメリットがあります：

* 動的な権限拡張：新しいカスタムリソース（CRD）を追加するとき、そのリソースの操作権限を独立したClusterRoleとして定義し、aggregate-to-*アノテーションを付与するだけで、既存のadminやviewなどの標準ロールが自動的に拡張されます。
* 運用負荷の軽減：複数のCRDを導入するたびに既存のClusterRoleを手動で編集する必要がありません。RBACポリシーの再定義作業を減らすことができます。
* 可読性・拡張性の向上：ロールを細かく分けて管理しつつ、それらを自動的に集約できるので、権限管理がスケールしやすくなります。

## 仕組みの概要

Kubernetesは、あるClusterRoleに特定のアノテーション（rbac.authorization.k8s.io/aggregate-to-<role>: "true"）が付与されている場合、それを既存の<role>に自動的に権限統合します。代表的な対象となる既存ロールは以下の通りです：

* aggregate-to-admin: "true" → 既存のadminロールへ追加
* aggregate-to-edit: "true" → 既存のeditロールへ追加
* aggregate-to-view: "true" → 既存のviewロールへ追加

このアノテーションを使うことで、例えば新しく追加したCRDに関する操作権限を「editロールに付けたい」という場合、aggregate-to-edit: "true"を付けたClusterRoleを作るだけで良くなります。

## サンプル構成例

ここでは、MyCustomResourceというCRDを導入したと仮定しましょう。MyCustomResourceはmygroup.example.com/v1グループのmycustomresourcesリソースを持っているとします。

### 1. CRDの定義（例）

```yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: mycustomresources.mygroup.example.com
spec:
  group: mygroup.example.com
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
  scope: Namespaced
  names:
    plural: mycustomresources
    singular: mycustomresource
    kind: MyCustomResource
    shortNames:
      - mcr
```

このCRDが導入されると、mycustomresourcesというリソースがKubernetes APIに新たに追加されます。

### 2. CRD用のClusterRole作成

mycustomresourcesを操作できるClusterRoleを新規に定義します。このとき、aggregate-to-edit: "true"を付けておくことで、editロールを持つユーザーは、この新リソースへの編集権限を自動的に得られます。

```yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: mycustomresource-edit
  labels:
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
  - apiGroups: ["mygroup.example.com"]
    resources: ["mycustomresources"]
    verbs: ["create", "update", "patch", "delete", "get", "list", "watch"]
```

ポイントはmetadata.labels下のrbac.authorization.k8s.io/aggregate-to-edit: "true"というラベル（アノテーションではなくラベルですが、Aggregate ClusterRoleは当初アノテーションと呼ばれていましたが実際にはラベルが利用されています。Kubernetesのドキュメントやバージョンによって表記揺れがありますが、現在はラベルで指定します）。これにより、このmycustomresource-edit ClusterRoleはeditロールに自動的に集約されます。

### 3. 効果の確認

kubectl get clusterroles edit -o yamlでeditロールを確認すると、mycustomresourcesに関するルールが自動的に追加されていることがわかります。これで、既存のeditロールを持つユーザーは、追加の手続きなしでmycustomresourcesを操作できるようになります。

## 運用上のヒント

* 標準ロール以外への拡張：デフォルトではadmin, edit, viewロールへの集約が一般的ですが、独自のAggregate ClusterRoleメカニズムを使うことも可能です。その場合は自前の基底ロールを作成し、同様にラベルを設定しておきます。
* 権限の整理：CRDが増え続ける環境では、細かいClusterRoleを多数作成した上で、適宜Aggregate ClusterRole機能でまとめていくとスッキリします。これにより、「どのCRDがどのロールに集約されているか」を明示的に管理できます。

## まとめ

Aggregate ClusterRoleを活用することで、Kubernetes RBAC管理はより柔軟かつ拡張しやすくなります。新しいリソースやアドオンの追加に合わせて権限を与える際、従来は手動で既存ロールを編集していた部分を、この仕組みにより自動化・簡略化することが可能です。

これからカスタムリソースを積極的に活用していく方や、さまざまなアドオンを試していく方は、ぜひAggregate ClusterRoleを導入し、Kubernetes環境の運用性を大きく向上させてみてください。