見出し画像

KubernetesのClusterRole、どんなときに必要？

toshi

Kubernetes運用を進める中で、リソースへのアクセス管理は避けて通れないテーマです。特に、Namespaceをまたぐリソース管理が必要になると、効率的な権限設計が重要になってきます。そんなときに役立つのが「ClusterRole」です。この記事では、ClusterRoleのメリットと、それを活用したPrometheusの設定例をご紹介します。

Namespaceを超える権限設計の必要性

Kubernetesには「Role」と「ClusterRole」という2種類の権限定義があります。

  • Role: 特定のNamespace内で有効な権限を定義。例えば、「Namespace A内のPodのみ操作可能」という範囲を制限した設定ができます。

  • ClusterRole: クラスタ全体にわたる権限を定義。NodeやPersistentVolumeなど、Namespaceに依存しないリソースへのアクセスや、全Namespaceをまたいだ操作が可能です。

ClusterRoleを選ぶ最大の理由は、「複数のNamespaceを一括で管理できること」。Namespaceをまたいだ作業が必要になる場合、ClusterRoleは極めて有効な選択肢です。

例え話：RoleとClusterRoleを警備員に例えると

ちょっとしたイメージ例を挙げてみましょう。

Roleの場合

Roleは「1つの部屋だけを見張る警備員」です。たとえば、Namespace A内のPodだけを監視する必要があるなら、この設定で十分です。しかし、別のNamespaceを監視したくなった場合、もう1人警備員を雇う（新しいRoleを追加する）必要が出てきます。

ClusterRoleの場合

一方で、ClusterRoleは「建物全体を巡回する警備員」です。全てのNamespaceを横断的に監視する必要があるなら、この方法が効率的。モニタリングツールの導入など、複数のNamespaceを横断してデータを取得するケースでは、ClusterRoleが適しています。

モニタリングツールとClusterRoleの連携例

Prometheusなどのモニタリングツールは、Kubernetesクラスタ全体を横断的に監視します。以下の設定例では、ClusterRoleとClusterRoleBindingを活用して、PrometheusがすべてのNamespaceのPodを監視できるようにしています。

ClusterRoleの設定例

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitor-all-pods
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

このClusterRoleでは、以下の権限を全Namespace内のPodに付与しています：

  • get: Podの詳細情報を取得

  • list: Podの一覧を取得

  • watch: Podの状態をリアルタイムで監視

ClusterRoleBindingの設定例

ClusterRoleをサービスアカウントに紐付けるには、ClusterRoleBindingを使います。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitor-all-pods-binding
subjects:
- kind: ServiceAccount
  name: monitoring-sa
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: monitor-all-pods
  apiGroup: rbac.authorization.k8s.io

この設定により、monitoring Namespaceのmonitoring-saサービスアカウントがClusterRoleの権限を使用できるようになります。

Prometheusの設定例

ClusterRoleとClusterRoleBindingを設定したら、Prometheusがその権限を使用してPod情報を取得できるようにします。以下は、PrometheusのDeployment設定例です。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: prometheus
  namespace: monitoring
spec:
  template:
    spec:
      serviceAccountName: monitoring-sa

この設定により、Prometheusはmonitoring-saサービスアカウントを利用し、全NamespaceのPod情報を収集できます。

将来の運用を見据えたClusterRoleの選択

ClusterRoleを採用することには、現在だけでなく将来の運用をスムーズにするメリットがあります。

  1. Namespace追加への柔軟な対応
    新たにNamespaceが追加されても、ClusterRoleなら既存の設定を変更する必要がありません。例えば、Prometheusは追加されたNamespaceのリソースも自動的に監視します。

  2. 権限管理の簡素化
    複数のNamespaceごとにRoleを設定するのは煩雑になりがちです。ClusterRoleを活用すれば、一括で権限を管理できます。

セキュリティリスクへの注意

ClusterRoleを使うと権限が広範になるため、以下のポイントに注意しましょう。

  • 最小権限の原則を守る: 必要最低限の操作だけを許可する。

  • 使用主体を明確に限定: 特定のサービスアカウントだけに権限を付与する。

  • 権限の定期的な見直し: 不要な権限が付与されていないかを定期的に確認する。

まとめ

ClusterRoleは、Kubernetes運用において効率的で拡張性のある権限設計を可能にします。

  • Namespaceを超えた監視や操作が必要な場合に最適。

  • モニタリングツールの導入で特に効果を発揮。

  • 現在の管理負担を軽減し、将来的な拡張にも柔軟に対応。

具体的には、以下の手順でPrometheusのようなモニタリングツールをセットアップできます。

  1. ClusterRoleで全NamespaceのPod操作権限を定義。

  2. ClusterRoleBindingでサービスアカウントに権限を付与。

  3. PrometheusのDeploymentでそのサービスアカウントを設定。

これにより、Prometheusは全NamespaceのPod情報を効率的に収集できるようになります。最小権限の原則を守りつつ、ClusterRoleを活用した効率的なKubernetes運用を目指してみてください！

いいなと思ったら応援しよう！