LoginSignup
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@reoring(れおりん)inCraftsman Software

RbacManagerの基本使用方法と実践例

Posted at

RbacManagerとは何か（概要）

RbacManagerは、KubernetesクラスタにおけるRBAC（Role-Based Access Control）設定を簡素化するためのオペレーターです (Rbac Manager Documentation)。通常、ユーザーやサービスアカウントごとにRoleBindingやClusterRoleBindingを手作業で作成・管理しますが、RbacManagerを導入するとRBAC設定を宣言的（Declarative）に管理できます。専用のカスタムリソース定義（CRD）であるRBACDefinitionを用いて望ましいアクセス権限の状態を記述すると、RbacManagerがそれを検知して必要なRoleBindingやServiceAccountなどを自動的に作成・更新・削除し、クラスターの実際の状態を定義どおりに保ちます (Rbac Manager Documentation) (RBAC Definitions | Rbac Manager Documentation)。これにより、権限付与の手順が大幅に簡略化され、ヒューマンエラーの削減や一貫したアクセス管理が実現できます (Must know tools for effortless Kubernetes management)。

RbacManagerの主な目的は以下の3点に要約できます (Introduction | Rbac Manager Documentation):

  • 宣言的でスケーラブルなRBAC管理: YAMLによる一括定義で、煩雑になりがちなRBAC設定を扱いやすくします。
  • 設定の簡素化: 繰り返しが多い権限設定をまとめて記述でき、必要な設定量を大幅に削減します（場合によっては半分以下） (Introduction | Rbac Manager Documentation)。
  • CI/CDとの統合: RBACポリシーの更新をコード管理し、自動デプロイ（GitOps）的な運用を可能にします。

RbacManager自体はKubernetes上で1つのコントローラ（オペレータ）Podとして動作し、このコントローラがRBACDefinitionリソースの作成・変更を監視して、クラスタ内のRBAC設定を所定の状態に調整します (Rbac Manager Documentation)。例えば、新しいユーザーに特定の名前空間へのアクセス権を与えたい場合、RBACDefinitionにそのユーザーと権限を追加するだけで、対応するRoleBindingが自動作成されます。また、定義から権限を削除すれば不要になったRoleBindingが自動で削除されるなど、RBAC設定のライフサイクル管理も容易になります (Introduction | Rbac Manager Documentation)。

KubernetesにおけるRBACの基礎概念

KubernetesのRBACは「Role Based Access Control」、すなわちロールに基づくアクセス制御を意味します (Kubernetes RBACの理解： 主な概念と例を紹介)。Kubernetesのコアなセキュリティ仕組みの一つであり、ユーザーやサービスアカウントに対して適切な権限を付与・管理するために用いられます (Kubernetes RBACの理解： 主な概念と例を紹介)。まずRBACの基本要素を整理します。

  • Role（ロール）: 名前空間内における一連の権限を定義するオブジェクトです。例えば、あるNamespace内のPodの閲覧・作成ができる、といったルールをRoleとして定義できます。
  • ClusterRole（クラスターロール）: クラスター全体に適用される権限セットを定義するオブジェクトです。Nodeの管理など、クラスターレベルのリソースに対する権限や、複数のNamespaceで共通に使いたい権限セットを定義できます（ClusterRoleは後述のRoleBindingを使うことでNamespace内の権限として再利用することも可能です (RBAC認可を使用する | Kubernetes)）。
  • RoleBinding（ロールバインディング）: あるRoleで定義された権限を、特定のsubjects（主体）に付与するオブジェクトです (RBAC認可を使用する | Kubernetes)。subjectsとはユーザー、グループ、サービスアカウントなど権限付与の対象となるエンティティで、RoleBindingはそれら主体のリストと参照するRole（またはClusterRole）を指定します (RBAC認可を使用する | Kubernetes)。RoleBindingによる権限付与の有効範囲は1つのNamespace内に限られます (RBAC認可を使用する | Kubernetes)。
  • ClusterRoleBinding（クラスターロールバインディング）: ClusterRoleで定義された権限をsubjectsに付与するオブジェクトです。ClusterRoleBindingを使うと、その権限はクラスター全体（全Namespace）に及びます (RBAC認可を使用する | Kubernetes)。言い換えれば、ClusterRoleBindingはクラスター範囲の権限付与に使用します。

上記4種のオブジェクト（Role, ClusterRole, RoleBinding, ClusterRoleBinding）がKubernetes RBACの中核であり (RBAC認可を使用する | Kubernetes)、適切に組み合わせることで「誰が（subjects）」「何に（リソース）」「何ができるか（動作）」を細かく制御できます。典型的には、クラスター管理者はClusterRoleやRoleを定義し、ユーザーやチームごとにRoleBinding/ClusterRoleBindingを作成して権限を割り当てます。例えば「Aliceというユーザーに開発用Namespaceで編集権限を与える」には、そのNamespace用のRole（または共通ClusterRole）を用意し、Aliceを主体としたRoleBindingを作成するといった手順になります。

しかしチームや環境が増えるにつれ、個別のRoleBinding YAMLを何度も記述・管理するのは煩雑になりがちです。一貫した命名や不要になった権限の削除漏れなど、人手による管理にはミスのリスクも伴います (Must know tools for effortless Kubernetes management)。そこで役立つのがRbacManagerによるRBACの自動化です。

RbacManagerのインストールと基本的な使い方

RbacManagerを使用するための基本手順は以下のとおりです。

1. オペレーターの導入: RbacManagerはKubernetes上で動作するコントローラとして提供されており、HelmチャートまたはYAMLマニフェストでインストールできます。 (Introduction | Rbac Manager Documentation)たとえばHelmを利用する場合、以下のコマンドでリポジトリ追加とデプロイが可能です (Introduction | Rbac Manager Documentation):

helm repo add fairwinds-stable https://charts.fairwinds.com/stable  
helm install rbac-manager fairwinds-stable/rbac-manager --namespace rbac-manager --create-namespace

Helmを使用しない場合は、公式リポジトリのdeploy/ディレクトリにあるマニフェスト一式を直接適用してインストールすることもできます (Introduction | Rbac Manager Documentation):

kubectl apply -f https://raw.githubusercontent.com/FairwindsOps/rbac-manager/master/deploy/all.yaml

※補足: RbacManagerは高い権限でクラスタ内のRBAC設定を操作するため、インストールするNamespace（上記例ではrbac-manager）や対象クラスターのセキュリティ設定に留意してください。RBACDefinitionリソースの作成権限はクラスター管理者のみに与え、一般ユーザーが誤って操作できないようにすることがベストプラクティスです（後述のベストプラクティス参照）。

2. RBACDefinitionリソースの記述: RbacManagerインストール後は、新たに提供されるCRD「RBACDefinition」を使ってアクセス権の希望状態を記述します。RBACDefinitionはクラスタスコープのカスタムリソースで、以下のような構造を持ちます (RBAC Definitions | Rbac Manager Documentation) (RBAC Definitions | Rbac Manager Documentation)。

apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
  name: <任意の名前>           # このRBAC定義の名前
rbacBindings:
  - name: <バインディング名1>  # 論理的な権限セットの名前（任意）
    subjects:                  # 権限を与える対象（ユーザー/グループ/サービスアカウント）のリスト
      - kind: User             # 種類: ユーザー
        name: alice@example.com
      - kind: User             # 複数指定も可能
        name: bob@example.com
      # ...（GroupやServiceAccountも指定可能）
    roleBindings:              # 付与する権限（ロール）のリスト
      - namespace: dev         # 対象とするNamespace
        clusterRole: edit      # 付与するClusterRole名（またはRole名）
      - namespace: staging
        clusterRole: view
  - name: <バインディング名2>  # 複数の権限セットを1つのRBACDefinitionにまとめて記述可能
    subjects:
      - kind: ServiceAccount
        name: ci-bot
        namespace: ci         # SAの場合はNamespaceも指定
    roleBindings:
      - clusterRole: edit
        namespaceSelector:    # Namespaceを名前ではなくラベルセレクタで指定
          matchLabels:
            team: dev

上記は構造の一例ですが、ポイントとして**rbacBindings配下に複数のエントリ**を定義でき、それぞれにsubjectsリストとroleBindingsリストを持ちます (RBAC Definitions | Rbac Manager Documentation) (RBAC Definitions | Rbac Manager Documentation)。各エントリが「特定の主体に対し一連のロールを与える」設定単位になっています。subjectsにはKindとしてUser（ユーザー）, Group（グループ）, ServiceAccount（サービスアカウント）を指定できます (RBAC Definitions | Rbac Manager Documentation)。roleBindingsには実際に付与したいRole/ClusterRoleとその適用範囲（namespaceまたはnamespaceSelector）を指定します。

  • namespaceフィールドにはNamespace名を直接指定し、そのNamespace内にRoleBindingを作成します。加えるclusterRoleフィールドには付与したい既存のClusterRole名（あるいはRole名）を指定します。ClusterRoleを指定した場合、そのRoleBindingはClusterRoleを参照しつつNamespace内に権限を付与する形となります (RBAC認可を使用する | Kubernetes)（KubernetesではRoleBindingでClusterRoleを参照しNamespace単位の権限付与が可能です）。
  • namespaceSelectorフィールドを使用すると、Namespace名の代わりにラベルセレクタでNamespaceを動的に選択できます (Introduction | Rbac Manager Documentation)。例えば上記例のようにmatchLabelsでteam: devというラベルを指定すると、そのラベルを持つ全てのNamespaceに対して対象権限を自動付与できます (Introduction | Rbac Manager Documentation)。Namespaceの追加・削除にも自動で追従するため、動的にNamespaceが増減する環境で非常に便利な機能です。

3. RBACDefinitionの適用: RBACDefinitionリソースのYAMLを作成したら、通常のKubernetesリソースと同様にkubectl apply -f <file>でクラスタに適用します。適用後、RbacManagerのコントローラが新規または更新されたRBACDefinitionを検知し、そこに定義された**desired state（望まれる状態）**と現在のRBAC設定を比較します (Introduction | Rbac Manager Documentation)。差分があれば、以下のようなリソースを自動的に生成・更新します (RBAC Definitions | Rbac Manager Documentation) (RBAC Definitions | Rbac Manager Documentation)。

  • 指定されたServiceAccountが存在しない場合、自動的にServiceAccountリソースを作成
  • 各roleBindingsエントリに対応して、対象NamespaceにRoleBindingを作成（または更新）
  • ClusterRoleBindingの指定がある場合はClusterRoleBindingを作成（例: クラスター全体に権限を与える場合）
  • RBACDefinitionから削除されたエントリに対応する既存のRoleBinding/ClusterRoleBindingがあれば、それらを自動削除 (Introduction | Rbac Manager Documentation)

一例として、先ほどのYAML例に含まれる設定からRbacManagerが作成する具体的なリソースを整理すると次のようになります (RBAC Definitions | Rbac Manager Documentation)。

  • ユーザーalice@example.comとbob@example.comに対し、Namespace「dev」でedit権限を与えるRoleBinding（ClusterRoleeditを参照）
  • 同上の2ユーザーに対し、Namespace「staging」でview権限を与えるRoleBinding
  • ServiceAccount ci-bot（Namespace:ci）が存在しなければ新規作成
  • ServiceAccount ci-botに対し、ラベルteam=devを持つ全てのNamespaceにおいてedit権限を与えるRoleBinding（各該当Namespaceに作成）
  • ServiceAccount ci-botに対し、ラベルapp=webまたはapp=queueを持つ全てのNamespaceにおいてadmin権限を与えるRoleBinding（各該当Namespaceに作成）

このように1つのRBACDefinition定義から複数のRBACリソースを自動生成できる点がRbacManagerの強力な特徴です (RBAC Definitions | Rbac Manager Documentation)。特に複数ユーザーへの複数Namespaceにまたがる権限付与や、Namespaceのラベルによる動的な権限適用といったシナリオで、手作業なら多数のYAMLに分散しがちな設定を一元的に管理できます。

また、RbacManagerを用いることで次のような従来困難だった管理も容易になります:

  • ロール変更の適用: 既存のKubernetes RoleBindingでは、一度バインドしたRoleを後から変更できないため、ロールの変更時には手動でRoleBindingを削除・再作成する必要がありました (Introduction | Rbac Manager Documentation)。RbacManagerでは、RBACDefinition内の該当エントリを書き換えるだけで、新しいロールへのバインドに自動更新されます (Introduction | Rbac Manager Documentation)。
  • 権限剥奪の検知: 権限を外す（RoleBindingを削除する）操作は、YAMLの管理下で抜け漏れなく行うのが難しい場合があります。RbacManagerの場合、各RBACDefinitionが「自分が作成したリソース」を追跡しており、定義から削除されたRoleBindingは検知次第自動でクラスター上から削除されます (Introduction | Rbac Manager Documentation)。これにより、不要な権限を確実に取り下げられ、セキュリティリスクの低減につながります。

実践例: アプリケーション開発者向けの権限管理

ここでは、アプリケーション開発者に典型的な権限を付与するユースケースでのRbacManager活用例を示します。たとえば、あるプロジェクトの開発チームのメンバーに対して、開発用Namespaceでは広範な編集権限を与え、本番Namespaceでは閲覧のみに制限するというシナリオを考えます。このような分離は、開発者が誤って本番環境に影響を及ぼさないようにするベストプラクティスです。

従来であれば、各開発者ごとにRoleBindingを2つ（開発Namespace用と本番Namespace用）作成し、適切なRole（またはClusterRole）をバインドする必要がありました。しかしRbacManagerを使えば、1つのRBACDefinitionでチーム全体の権限を一括管理できます。

例えば、「dev-team」というグループ（社内のユーザーグループを想定）があり、devというNamespace（開発環境）では編集（edit）権限、prodというNamespace（本番環境）では閲覧（view）権限を与える場合、以下のようなRBACDefinitionを作成できます。

apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
  name: dev-team-access
rbacBindings:
  - name: dev-team-permissions
    subjects:
      - kind: Group
        name: dev-team                   # 開発者チームのグループ名
    roleBindings:
      - clusterRole: edit
        namespace: dev                   # 開発環境Namespaceに編集権限を付与
      - clusterRole: view
        namespace: prod                  # 本番環境Namespaceに閲覧権限を付与

上記の定義をクラスタに適用すると、RbacManagerによって以下が実現されます。

  • グループdev-teamに属する全ユーザーに対し、Namespace「dev」での編集権限（Kubernetes既定のClusterRoleeditに相当）を付与するRoleBindingが作成される
  • 同じくdev-teamの全ユーザーに対し、Namespace「prod」での閲覧権限（ClusterRoleview）を付与するRoleBindingが作成される

これによって、チームの新メンバー追加や離脱にも柔軟に対応できます。ユーザーのグループ所属さえ更新すれば、クラスター側のRBACは自動的に適用されるため、チーム単位で一貫したアクセス権管理が可能です。開発者に必要最小限の権限を与えつつ、ポリシー逸脱を防げる点で安全性と利便性のバランスが取れています。

さらに、例えば別のNamespace（ステージング環境など）を追加して同じ開発チームに編集権限を与えたい場合も、RBACDefinitionのroleBindingsにエントリを1行追加して再適用するだけで済みます。複数のRoleBinding定義が一箇所にまとまっているため変更漏れが起きにくく、変更履歴も一目で把握できます。

実践例: チームごとのアクセス制御と動的Namespace管理

大規模な組織ではチームやプロジェクトごとにNamespaceを分離し、チーム単位でアクセス制御を行うケースが多くあります。RbacManagerは、このようなマルチテナンシー環境でも効率的にRBAC管理を行うのに役立ちます。

典型的な例として、Namespaceの命名やラベルによってチームを識別し、チーム毎に適切な権限を自動付与する方法があります。RbacManagerのnamespaceSelector機能を使えば、Namespaceが増減してもラベルさえ統一ルールで管理しておけば、新規Namespaceにも自動で権限が適用されます (Introduction | Rbac Manager Documentation)。

例えば、クラスタ上に各開発チーム用のNamespaceを動的に作成していく運用を考えます。各Namespaceにはその所属チームを示すラベル（ここではteamラベル）を付与しておき、RbacManager側で「チームXのグループには、team=Xというラベルを持つすべてのNamespaceで編集権限を与える」よう定義します。

具体的には、あるチーム「alpha-team」に対し、以下のようなRBACDefinitionを用意します。

apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
  name: alpha-team-access
rbacBindings:
  - name: alpha-team-permissions
    subjects:
      - kind: Group
        name: alpha-team                # チームAlphaの社内グループ
    roleBindings:
      - clusterRole: admin
        namespaceSelector:
          matchLabels:
            team: alpha                 # ラベル team=alpha を持つNamespace全てにadmin権限を付与

この定義により、チームAlphaのメンバーはNamespaceの名前に依存せず、ラベルベースで自分たちの領域にアクセスできます。具体的には、team=alphaというラベルが付いたNamespace（例: alpha-dev, alpha-prod など複数存在し得る）がクラスタ内にあれば、その全てに対してClusterRoleadmin（Namespace管理者相当の権限）が自動付与されます。新たにteam=alphaのNamespaceを追加しても、RbacManagerが即座に検知して該当NamespaceにRoleBindingを作成するため、追加のRBAC設定作業は不要です (Introduction | Rbac Manager Documentation)。逆にNamespaceを削除した場合も、そのNamespaceに紐づくRoleBindingはRbacManagerによって自動的にクリーンアップされます。

このようなラベル活用によるRBAC管理は、チームごとのアクセス制御をスケーラブルに運用する上で非常に強力です。特にCI/CDパイプラインでNamespaceを動的に生成・破棄するケース（プレビュー環境の自動作成など）でも、事前にラベルとRBACDefinitionのルールを決めておけば人手を介さず安全な権限設定が維持できます。

なお、チームごとのアクセス制御ではグループを使った管理も重要です。上記の例ではGroupをsubjectsに指定しましたが、これは企業のシングルサインオン基盤やIDプロバイダとKubernetesを連携させ、ユーザーに所属グループ情報を持たせることで実現できます。RbacManagerはKubernetesの認証システムから渡されるユーザグループ（例: OpenID Connectのgroupsクレーム）をそのままsubjectsとして扱えるため、社内のチーム体制とクラスタ権限をコードで紐付けることが可能です。結果として、組織変更やメンバー異動の際もRBACDefinitionの記述をほとんど変更せずに対応できる柔軟性を持ちます。

便利な設定とベストプラクティス

最後に、RbacManagerを活用する上で知っておくと便利な設定や運用上のベストプラクティスについてまとめます。

  • ラベルセレクタの活用: 前述の通り、namespaceSelectorによってNamespaceラベルに基づく権限付与ができます。これを活用し、Namespaceにはチーム名や用途（dev/prodなど）を示すラベルを付与する運用にすると、RBACルールを簡潔かつ動的に保てます (Introduction | Rbac Manager Documentation)。新規Namespace追加時の権限付与忘れといった事態も防げます。
  • グループベースの権限管理: ユーザー個人ではなくグループ（組織のチームや役職）に対して権限を割り当てることで、ユーザーの出入りにも柔軟に対応できます。RbacManagerのsubjectsにGroupを使えば、社内ディレクトリのグループと連携した一括管理が可能です。グループメンバーの変更だけで権限も即時に反映されるため、最小限のオペレーションでセキュアな管理が実現します。
  • 権限は原則として最小限に: これはRBAC全般の原則ですが、与える権限は必要最小限に留めます。RbacManagerを使う場合も、例えば開発者にはeditやview程度にとどめ、cluster-adminのような強力すぎる権限は限定された管理者グループのみにClusterRoleBindingで与えるべきです。RbacManagerの定義ファイル自体に誰でもアクセスできないようにし、誤って過剰な権限を付与する事態を防ぎましょう。
  • RBACDefinitionの分割と命名: RbacManagerでは一つのRBACDefinitionに複数のrbacBindingsを含められますが、運用上は目的ごとにCRを分割することが望ましいです。例えば、チームA用の権限セットとチームB用の権限セットを別々のRBACDefinition（それぞれteam-a-access, team-b-access等）として管理すれば、変更履歴や責任の所在が明確になります。CRのmetadata.nameは内容を表す命名にしておくと、後から見返した際に分かりやすく便利です。
  • 設定の一元管理と監査: RBACDefinition（YAMLファイル）はGitなどのバージョン管理下に置き、Pull Requestを経てレビュー・適用する仕組みにすると変更履歴が残り安心です。RbacManagerを導入すると「RBAC設定が散在せず一箇所にまとまる」利点がありますので、ぜひコードリポジトリで一元管理しましょう。また、付与されている権限を定期的に見直すために、RbacManager開発元のFairwindsが提供する「rbac-lookup」などのツールと組み合わせて監査を行うのもベストプラクティスです (Introduction | Rbac Manager Documentation)。
2
0
1

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?