Contents
はじめに：Argo CD RBACの概要と目的
Kubernetes環境におけるアプリケーション管理ツールとして、Argo CDは広く利用されていますが、セキュリティ面での設定を軽視しがちです。特にロールベースアクセス制御（RBAC）の適切な実装は、不正アクセスや誤操作によるクラスター破損を防ぐための必須項目です。本記事では、Red Hat公式ドキュメントに基づき、Argo CDのRBAC設定手順とベストプラクティスをステップバイステップで解説します。キーワード「Argo CD RBAC 設定 方法」に沿った実務的な導線が得られることを目的としています。
argo-cd-rbac-cm ConfigMapの構造と基本設定
Argo CDのRBACは、argo-cd-rbac-cmというConfigMapを通じて管理されます。このConfigMapの構造を理解することで、ユーザーごとの権限設定を柔軟に制御できます。
ConfigMapの主なキーと役割
argo-cd-rbac-cmは以下の主要なキーを持ちます：
| 項目 | 説明 | 例 |
|---|---|---|
policy |
権限ルールを定義するセクション | - p, role:admin, resource:apps, action:* |
users |
ユーザーとロールのマッピング | "user1": "admin" |
groups |
グループとロールのマッピング | "devs": "developer" |
このConfigMapは、namespaceスコープおよびクラスタースコープの権限を一元管理できます。
デフォルトの権限設定例
初期状態では、argo-cd-rbac-cmは以下のような設定を持ちます：
|
1 2 3 4 5 6 |
policy: - p, role:admin, resource:apps, action:* - p, role:developer, resource:apps, action:get,list,watch users: admin: admin |
この設定では、adminロールを持つユーザーはすべてのアプリケーション操作を許可されますが、developerロールは読み取り専用に制限されています。
RoleとClusterRoleの定義方法
KubernetesでのRBACは、Role（namespaceスコープ）とClusterRole（クラスタースコープ）で構成されます。Argo CDではこれらのリソースを活用して、細かなアクセス権を設定します。
Namespace作用域のRole
アプリケーションごとのアクセス制限を行うには、Roleリソースを作成します。以下に手順を示します：
- 任意のNamespace（例:
argocd）でRoleを作成 appsなどのリソースに対する権限を定義
|
1 2 3 4 5 6 7 8 9 10 |
apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: argocd name: app-reader rules: - apiGroups: ["argoproj.io"] resources: ["applications"] verbs: ["get", "list", "watch"] |
このRoleは、アプリケーションの読み取り専用権限を付与します。
クラスタースコープのClusterRole
クラスターアクセスが必要な場合はClusterRoleを使用します。以下に例を示します：
|
1 2 3 4 5 6 7 8 9 |
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cluster-admin rules: - apiGroups: ["*"] resources: ["*"] verbs: ["*"] |
このClusterRoleは、クラスター全体の操作権を付与するため、慎重に使用することが重要です。Kubernetesベストプラクティスでは、namespace内でのRole利用が推奨されており、ClusterRoleは必要最小限に留める必要があります。
Policyルールの作成手順（p, , , ）
Argo CDのRBACポリシーはpolicyセクションで定義されます。形式は以下の通り：
|
1 2 |
p, <role>, <resource>, <action> |
許可ルールの記述形式
p: Allow（許可）を示す<role>: 定義されたロール名<resource>: 操作対象リソース<action>: 允許するアクション（例:get,update,delete）
注意:
resourceの記述形式にバージョン依存性があるため、apps/app1など具体的なパスを指定する代わりに、argoproj.io/v1alpha1などのAPIグループを含めた記述（例:argoproj.io/applications/app1）が推奨されます。
複数リソースへの適用例
以下は、複数のリソースに対して読み取り権限を付与する例です：
|
1 2 3 4 |
policy: - p, role:reader, resource:apps, action:get,list,watch - p, role:developer, resource:applications, action:get,list,watch |
この設定により、readerとdeveloperロールのユーザーはappsリソースに対して読み取り専用権限を持ちます。
ユーザー認証とRBACの連携方法
Argo CDではOAuthやLDAPなどの外部認証プロバイダと統合することで、セキュアなユーザー管理が可能です。その際には、argo-cd-rbac-cmに以下の情報を記載します：
OAuthやLDAP認証との統合
- 認証プロバイダ（例: Entra ID）の設定を完了
argo-cd-rbac-cmにユーザーとロールのマッピングを追加
|
1 2 3 4 5 |
users: "[メールアドレス削除]": "admin" groups: "developers": "developer" |
この設定により、[メールアドレス削除]はadminロールを持ち、developersグループはdeveloper権限を持つようになります。
ロールベースのアクセス制限設定
ユーザーごとのロールを明示することで、特定リソースへのアクセスを制御できます。例えば：
|
1 2 3 4 |
policy: - p, role:admin, resource:apps, action:* - p, role:viewer, resource:apps, action:get,list,watch |
アプリケーションごとの権限制限の実装例
特定アプリケーションにのみアクセスを許可するには、argocd-rbac-cmにアプリ名を指定してポリシーを定義します。
特定アプリへの限定アクセス
以下のように、apps/app1に対してのみ書き込み権限を与える設定例です：
|
1 2 3 |
policy: - p, role:developer, resource:apps/app1, action:update |
このケースでは、developerロールはapp1アプリケーションの更新操作のみを許可されます。
複数ロールの階層構造
複雑な権限管理を行うには、ルールグループを階層化して設定します：
|
1 2 3 4 |
policy: - p, role:admin, resource:apps, action:* - p, role:developer, resource:apps, action:get,list,watch |
ベストプラクティスと注意点
RBACはセキュリティの根幹を担うため、以下の点に注意が必要です。
最小権限原則の実践
不要なアクセス権を付与しないことで、リスクを最小化できます。たとえば：
developerロールには削除操作(delete)は許可しない- クラスタースコープのClusterRoleは極力使わない
変更後のテスト手順
設定変更後は必ずテストを実施します：
kubectl apply -f <rbac-file>.yamlで変更を適用- テストユーザーとしてArgo CDにログイン
- 指定された権限が正しく反映されているか確認
重要：RBACの誤設定により、クラスター全体へのアクセス制限が解除される可能性があるため、テストは非本番環境で先行テストを実施することを推奨します。
オーセンティケーションプロバイダ統合の手順
OAuth/LDAPなどの外部認証プロバイダと連携する際には、以下のステップを実施してください：
- Argo CDに認証プロバイダ（例: Entra ID）を登録
argo-cd-rbac-cmのusersおよびgroupsセクションにマッピング情報を追加config.yamlで認証設定を反映し、argocd config saveコマンドで保存- Argo CDを再起動して変更を適用
まとめ
Argo CDのRBAC設定は、クラスターのセキュリティと運用安定性にとって不可欠です。本記事では、ConfigMap構造、Role/ClusterRole定義、Policyルール作成、認証連携手順など、実務的なポイントを網羅しました。特にバージョン依存性のあるresourceの記述やClusterRoleの過剰利用回避といった注意点に留意し、最小権限原則に基づいた設計が求められます。