こんにちは!Kubernetes環境でGitOpsを運用していると、必ず直面する課題があります。それは、「誰が、どのプロジェクトに、どこまでアクセスできるのか?」という制御です。
本日は、Argo CDの権限制御エンジンであるargocd-rbac-cmの構造を掘り下げ、セキュリティの頂点とも言えるAppProjectベースのCI専用トークン発行方法まで詳しく見ていきましょう。🛠️

1. 🏗️ Argo CD RBACの心臓部:argocd-rbac-cmの概要
Argo CDは基本的にRole-Based Access Control (RBAC)モデルに従います。この設定を担当するConfigMapがargocd-rbac-cmです。
📋 主要構成要素
- Policy: p,
, , , - Scopes: どのグループ情報に基づいて権限を付与するかを決定します(例:GitHub Org、Keycloak Group)。
- Default Role: 権限が明示されていないユーザーに付与するデフォルトの権限です(一般的にrole:readonly権限が推奨されます)。
💻 argocd-rbac-cmの基本設定例
YAML
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-rbac-cm
namespace: argocd
data:
# 1. デフォルト権限設定:何の権限も持たないユーザーは読み取り専用に設定 🧐
policy.default: role:readonly
# 2. カスタムポリシー定義 📜
# 形式: p, <role/user/group>, <resource>, <action>, <object>, <allow/deny>
policy.csv: |
# 'dev-team'ロールは'default'プロジェクト内のすべてのアプリに対して'sync'と'get'権限を持つ
p, role:dev-team, applications, get, default/*, allow
p, role:dev-team, applications, sync, default/*, allow
# 特定のグループ(OIDC連携時)をロールにマッピング
g, "my-github-org:eng-team", role:dev-team
# 3. CSVデータソース設定(デフォルト)
scopes: '[groups]'
2. 🎯 特定プロジェクトのための役割:AppProject Role
すべてのユーザーにクラスタ全体の権限を与えることはできません。Argo CDはAppProjectという単位を通じて論理的な隔離を提供します。
🔍 AppProject Roleの利点
- マルチテナンシー: AチームはAプロジェクトのみ、BチームはBプロジェクトのみを管理するように強制します。
- きめ細やかな制御: プロジェクト内で「アプリケーションの作成」は可能だが、「プロジェクトの変更」は不可能に設定できます。
3. 🔑 CIパイプラインのためのスコープドトークン発行方法
最も重要な質問です。「JenkinsやGitHub ActionsのようなCIツールが、特定のプロジェクトにのみアクセスできるトークンを安全に取得するにはどうすればよいでしょうか?」 💡
グローバル管理者トークン(admin)を使用することは非常に危険です。代わりに、AppProject内部にRoleを作成し、そのRoleに紐付けられたトークンを発行する必要があります。
Step 1: AppProject内部にRoleを定義する
まず、AppProjectリソースを修正して、CI専用の役割を作成します。
YAML
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: ecommerce-project
namespace: argocd
spec:
description: "이커머스 서비스 전용 프로젝트"
# ... 既存設定省略 ...
roles:
# 1. 'ci-bot'という名前のロールを定義します。🤖
- name: ci-bot
description: "CI 파이프라인용 전용 토큰 역할"
policies:
# このロールはこのプロジェクト内部のアプリケーションに対してのみ更新/同期可能
- p, proj:ecommerce-project:ci-bot, applications, get, ecommerce-project/*, allow
- p, proj:ecommerce-project:ci-bot, applications, sync, ecommerce-project/*, allow
- p, proj:ecommerce-project:ci-bot, applications, update, ecommerce-project/*, allow
Step 2: Argo CD CLIを使用してトークンを発行する
Roleを作成したら、次にこのRoleに紐付けられたJWTトークンを生成する必要があります。この作業はArgo CD CLIを通じて行うのが最も簡単です。
Bash
# 1. 特定プロジェクトのRoleにトークン生成を要求
# --expires-in: トークン有効期限設定(例:1年 = 8760h)
argocd proj role generate-token ecommerce-project ci-bot --expires-in 8760h
⚠️ 注意: 出力されるトークン値は一度しか表示されないため、必ず安全な場所(Vault、GitHub Secretsなど)に保存してください!
Step 3: CI環境でトークンを活用する
発行されたトークンをCIツールの環境変数(例:ARGOCD_TOKEN)として登録し、次のように使用します。
Bash
# 別途ログインプロセスなしでトークンのみでコマンド実行可能!🚀
argocd app sync my-app --server argocd.example.com --auth-token $ARGOCD_TOKEN
4. 💡 運用ヒント:より安全なRBACのためのチェックリスト
- 最小権限の原則 (Principle of Least Privilege): policy.defaultをrole:adminに設定しないでください。role:readonlyまたは空のままにするのが安全です。
- グループベースの管理: 個々のユーザーにpポリシーを付与するのではなく、OIDC(Okta, Dex, GitHub)グループをg設定を通じてRoleにマッピングしてください。これにより管理効率が大幅に向上します。
- AppProjectトークン管理: CI用トークンは定期的に更新(Rotation)し、もはや使用しないトークンはargocd proj role delete-tokenコマンドで即座に破棄してください。
📝 要約テーブル
| 区分 | グローバルRBAC (argocd-rbac-cm) | プロジェクトRBAC (AppProject) |
|---|---|---|
| 管理範囲 | システム全体の権限 (Admin, Readonlyなど) | 特定プロジェクト内のリソース権限 |
| 主要対象 | 運用チーム、全開発者グループ | 特定サービス開発チーム、CIボット |
| トークン発行 | ローカルアカウント(Local User)ベース | プロジェクト役割(Project Role)ベース |
| 推奨用途 | システム全体のアクセス制御 | CI/CDパイプライン連携 (Scoped) |
—
💡 終わりに
Argo CDのセキュリティは、argocd-rbac-cmによる巨視的制御とAppProjectによる微視的制御の調和から始まります。特に本日ご紹介したCI専用スコープドトークンは、クラスタセキュリティの脅威を最小限に抑えつつ、自動化効率を高める最良の方法です。
ぜひ皆さんのGitOps環境にも今すぐ適用してみてください!ご不明な点があれば、コメントでお知らせください。😊
コメントを残す