ArgoCD の RBAC 設定と最小権限設計ガイド

2026年7月2日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 1. ArgoCD の RBAC 基本概念
- 1.1 1.1 RBAC が提供する主な機能
2 2. argocd-rbac-cm ConfigMap の構造と編集方法
3 3. 最小権限ロール設計と具体的設定例
- 3.1 3.1 ロール別許可範囲（概要）
- 3.2 3.2 CSV 定義例
4 4. 外部認証プロバイダー（OIDC・LDAP・SAML）との連携手順
5 5. プロジェクト単位でのアクセス制御とリスク低減策
6 6. 監査・運用・バージョンアップ時の注意点
7 7. 記事まとめ

スポンサードリンク

1. ArgoCD の RBAC 基本概念

ArgoCD は内部で Casbin ベースのポリシーエンジンを使用し、認可情報は argocd-rbac-cm ConfigMap に保存されます。
この仕組みを理解すれば、Kubernetes の Role と同様に ロール と ポリシー を組み合わせて細かい操作権限を付与でき、誤操作や不正アクセスのリスクを抑えられます。

1.1 RBAC が提供する主な機能

ユーザー・グループ単位で API エンドポイントへの allow/deny を定義
プロジェクトやクラスター単位で権限のスコープを限定可能
Dex と組み合わせた外部 IdP（OIDC、LDAP、SAML）から取得した属性を直接 RBAC にマッピング

2. `argocd-rbac-cm` ConfigMap の構造と編集方法

ArgoCD の RBAC 設定はすべてこの ConfigMap に集約されます。
正しい手順で取得・編集し、Helm/Kustomize と連携させることで、GitOps 方式で安全に権限管理を自動化できます。

2.1 ConfigMap の取得と保存

argocd-rbac-cm は ArgoCD がインストールされた名前空間（デフォルトは argocd）に存在します。以下のコマンドで内容をローカルに保存し、エディタで修正しましょう。

kubectl -n argocd get configmap argocd-rbac-cm -o yaml &gt; rbac-config.yaml

1 2	kubectl -n argocd get configmap argocd-rbac-cm -o yaml > rbac-config.yaml

2.2 主なキーとフォーマット

キー	用途	記述例
`policy.csv`	ロール・ポリシーを CSV 形式で定義（必須）	`g, dev-team, role:project-admin`
`scopes` (任意)	Project/Cluster スコープの追加制約	`projects: my-project`
`policy.default` (任意)	ポリシーがマッチしないユーザーに付与するデフォルトロール	`p, , applications, get, , allow`

注：公式ドキュメントでは policy.default は「未定義ユーザーへのフォールバック」として紹介されていますが、実際の利用は環境ごとに異なるため、導入前に動作確認を行ってください。

2.3 Helm/Kustomize での上書き例

# values.yaml（Helm）
configs:
  rbac:
    policyCSV: |
      g, admins, role:admin
      p, role:admin, *, *, *, *, allow

# values.yaml（Helm）

configs:

rbac:

policyCSV: |

g, admins, role:admin

p, role:admin, *, *, *, *, allow

helm upgrade --install argocd argo/argo-cd -f values.yaml とすれば ConfigMap が自動生成されます。

3. 最小権限ロール設計と具体的設定例

実務で頻繁に使われるロールを admin, project-admin, read-only の三層に絞り、各ロールの許可範囲と CSV 定義を示します。

3.1 ロール別許可範囲（概要）

ロール	主な権限	利用シーン
admin	全リソース・全操作の無制限アクセス	緊急障害対応やクラスター管理者向け
project‑admin	所属 Project 内のアプリ作成・更新・削除	チーム単位でプロジェクトを所有するケース
read-only	UI/CLI の閲覧と監査ログ取得のみ	ステークホルダーや外部監査人向け

3.2 CSV 定義例

# admin ロール（全権限）
g, admins, role:admin
p, role:admin, *, *, *, *, allow

# project-admin ロール（my-project に限定）
g, dev-team, role:project-admin
p, role:project-admin, applications, *, my-project/*, allow
p, role:project-admin, projects, get, my-project, allow

# read-only ロール（閲覧専用）
g, auditors, role:read-only
p, role:read-only, applications, get, *, allow
p, role:read-only, projects, get, *, allow

# admin ロール（全権限）

g, admins, role:admin

p, role:admin, *, *, *, *, allow

# project-admin ロール（my-project に限定）

g, dev-team, role:project-admin

p, role:project-admin, applications, *, my-project/*, allow

p, role:project-admin, projects, get, my-project, allow

# read-only ロール（閲覧専用）

g, auditors, role:read-only

p, role:read-only, applications, get, *, allow

p, role:read-only, projects, get, *, allow

ポイント：* を乱用せず、リソースやオブジェクトはできるだけ具体的に限定することで過剰権限付与を防げます。

4. 外部認証プロバイダー（OIDC・LDAP・SAML）との連携手順

ArgoCD は Dex を組み込んで外部 IdP と統合できます。以下では、代表的な 3 種類の接続設定と注意点をまとめます。

4.1 OIDC 設定例（Google）

GitHub は標準的な OIDC Issuer ではなく認証フローが異なるため、本稿では Google を例に示します。

# values.yaml に記述する例
dex:
  connectors:
    - type: oidc
      id: google
      name: Google
      config:
        issuer: https://accounts.google.com
        clientID: &lt;client-id&gt;
        clientSecret: &lt;client-secret&gt;
        redirectURI: https://argocd.example.com/api/dex/callback
        scopes: [&quot;openid&quot;, &quot;email&quot;, &quot;profile&quot;]
        userIDKey: sub          # ユーザー一意識別子
        groupsKey: hd           # Google Workspace のドメインをロールにマッピング例

# values.yaml に記述する例

dex:

connectors:

- type: oidc

id: google

config:

issuer: https://accounts.google.com

clientID: <client-id>

clientSecret: <client-secret>

redirectURI: https://argocd.example.com/api/dex/callback

scopes: ["openid", "email", "profile"]

userIDKey: sub # ユーザー一意識別子

groupsKey: hd # Google Workspace のドメインをロールにマッピング例

groupsKey で取得した属性は g, <group>, role:<role> に利用でき、Google Workspace の組織単位ごとにロール割当が可能です。

4.2 LDAP バインド設定の要点

項目	設定例
host	`ad.example.com:636`（LDAPS）
bindDN	`CN=argocd,OU=ServiceAccounts,DC=example,DC=com`
userSearch.baseDN	`OU=Users,DC=example,DC=com`
groupSearch.filter	`(objectClass=group)`
userMatchers	`userAttr: DN`, `groupAttr: member`

dex:
  connectors:
    - type: ldap
      id: ad
      name: ActiveDirectory
      config:
        host: ad.example.com:636
        insecureNoSSL: false
        bindDN: CN=argocd,OU=ServiceAccounts,DC=example,DC=com
        bindPW: &lt;password&gt;
        userSearch:
          baseDN: OU=Users,DC=example,DC=com
          filter: &quot;(objectClass=user)&quot;
          username: sAMAccountName
          idAttr: DN
          emailAttr: mail
          nameAttr: displayName
        groupSearch:
          baseDN: OU=Groups,DC=example,DC=com
          filter: &quot;(objectClass=group)&quot;
          userMatchers:
            - userAttr: DN
              groupAttr: member
          nameAttr: cn

dex:

connectors:

- type: ldap

id: ad

config:

host: ad.example.com:636

insecureNoSSL: false

bindDN: CN=argocd,OU=ServiceAccounts,DC=example,DC=com

bindPW: <password>

userSearch:

baseDN: OU=Users,DC=example,DC=com

filter: "(objectClass=user)"

username: sAMAccountName

idAttr: DN

emailAttr: mail

nameAttr: displayName

groupSearch:

baseDN: OU=Groups,DC=example,DC=com

filter: "(objectClass=group)"

userMatchers:

- userAttr: DN

groupAttr: member

nameAttr: cn

4.3 SAML 連携の概略手順

IdP（例：Okta、Azure AD）からメタデータ XML を取得し dex の saml コネクタに貼り付け。
attributeMapping に role → group のマッピングを定義。
ArgoCD UI の Settings > SSO でエンドポイント URL と証明書を設定。

注意点：SAML は署名・暗号化が必須になるケースが多く、証明書の有効期限管理を別途ドキュメント化しておきましょう。

5. プロジェクト単位でのアクセス制御とリスク低減策

ArgoCD の AppProject は名前空間・リポジトリへのアクセス範囲を限定でき、RBAC と組み合わせることで粒度の細かい権限管理が実現します。

5.1 Project スコープにロールを埋め込む例

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: my-project
  namespace: argocd
spec:
  sourceRepos:
    - https://github.com/example/repo.git
  destinations:
    - namespace: prod
      server: https://kubernetes.default.svc
  role:
    - name: devops
      description: &quot;Deploy to prod in my-project&quot;
      policies:
        - p, role:devops, applications, sync, my-project/*, allow
      groups:
        - dev-team

apiVersion: argoproj.io/v1alpha1

kind: AppProject

metadata:

namespace: argocd

spec:

sourceRepos:

- https://github.com/example/repo.git

destinations:

- namespace: prod

server: https://kubernetes.default.svc

role:

- name: devops

description: "Deploy to prod in my-project"

policies:

- p, role:devops, applications, sync, my-project/*, allow

groups:

- dev-team

devops ロールは my-project のアプリケーションに対して sync（デプロイ）操作だけを許可し、他のプロジェクトには影響しません。

5.2 Sync Window による時間帯制御

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: my-project
spec:
  syncWindows:
    - kind: allow
      schedule: &quot;0 9 * * MON-FRI&quot;
      duration: 8h   # 平日 09:00‑17:00 のみ自動同期許可

apiVersion: argoproj.io/v1alpha1

kind: AppProject

metadata:

spec:

syncWindows:

- kind: allow

schedule: "0 9 * * MON-FRI"

duration: 8h # 平日 09:00‑17:00 のみ自動同期許可

平日業務時間外は手動承認が必要になるため、夜間の誤デプロイリスクを低減できます。

5.3 Automation Policy で自動修復を制御

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: prod-appset
spec:
  generators:
    - list:
        elements:
          - cluster: prod-cluster
            repoURL: https://github.com/example/prod.git
  template:
    metadata:
      name: &quot;{{cluster}}-app&quot;
    spec:
      project: my-project
      syncPolicy:
        automated:
          prune: true
          selfHeal: false   # ドリフト検出時に自動復旧しない

apiVersion: argoproj.io/v1alpha1

kind: ApplicationSet

metadata:

spec:

generators:

- list:

elements:

- cluster: prod-cluster

repoURL: https://github.com/example/prod.git

template:

metadata:

spec:

project: my-project

syncPolicy:

automated:

prune: true

selfHeal: false # ドリフト検出時に自動復旧しない

selfHeal: false にすることで、重大変更があった際は必ず人間のレビューを経てから再デプロイできます。

6. 監査・運用・バージョンアップ時の注意点

RBAC の安全性は設定だけでなく、継続的な監査と適切なバージョン管理が不可欠です。以下のベストプラクティスを実装しましょう。

6.1 監査ログ取得と可視化

ArgoCD は audit.log に認証・認可イベントを出力します。Kubernetes のロギング基盤（例：Fluent Bit → Elasticsearch）へ転送し、検索可能にするとインシデント調査が迅速になります。

# argocd-cm (configs.secret) に audit 有効化設定例
configs:
  secret:
    argocd-cm: |
      # Enable audit logging
      &quot;application.instanceLabelKey&quot;: &quot;argocd.argoproj.io/instance&quot;

# argocd-cm (configs.secret) に audit 有効化設定例

configs:

secret:

argocd-cm: |

# Enable audit logging

"application.instanceLabelKey": "argocd.argoproj.io/instance"

6.2 インシデント時のトラブルシューティング手順

audit.log から対象ユーザー・操作時間を抽出（例：grep "<user>" /var/log/argocd/audit.log）
影響した Application を特定し、必要なら argocd app rollback で復旧
過剰権限が付与されていないかロール・ポリシーを再評価

6.3 バージョンアップ時の RBAC 移行チェックリスト

項目	確認ポイント
ConfigMap 名称	`argocd-rbac-cm` が残っているか
`policy.csv` フィールド	非推奨フィールド（例：`action` の旧表記）が無いか
デフォルトポリシー	`policy.default` のマージ結果が期待通りか
スコープ設定	Project/Cluster のスコープキーが新バージョンで変更されていないか
Dex コネクタ	OIDC/Ldap/SAML の定義に破壊的変更が無いか

アップグレード前に helm diff や kubectl diff -f で差分を確認し、ステージング環境で動作検証することを推奨します。

6.4 CI/CD パイプラインでの RBAC 自動適用例

# .github/workflows/argocd-rbac.yml
name: Apply ArgoCD RBAC
on:
  push:
    paths:
      - 'rbac/**'
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set Kubeconfig
        run: echo &quot;${{ secrets.KUBECONFIG }}&quot; &gt; $HOME/.kube/config
      - name: Apply RBAC ConfigMap
        run: kubectl apply -f rbac/argocd-rbac-cm.yaml

# .github/workflows/argocd-rbac.yml

on:

push:

paths:

- 'rbac/**'

jobs:

deploy:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v3

- name: Set Kubeconfig

run: echo "${{ secrets.KUBECONFIG }}" > $HOME/.kube/config

- name: Apply RBAC ConfigMap

run: kubectl apply -f rbac/argocd-rbac-cm.yaml

rbac/argocd-rbac-cm.yaml に最新の policy.csv と任意の scopes を記述しておけば、プッシュ時に自動で ArgoCD に反映されます。設定変更履歴が Git で管理できるため、監査証跡も確保できます。

7. 記事まとめ

RBAC の核は argocd-rbac-cm ConfigMap。CSV 形式でロールとポリシーを定義し、必要に応じて policy.default でフォールバック設定を行う。
最小権限設計 として admin, project-admin, read-only の三層ロールを作成し、リソースはできるだけ具体的に限定することで過剰権限付与を防止。
外部認証（OIDC・LDAP・SAML） を Dex と連携させ、IdP の属性マッピングで RBAC グループへ自動割当が可能。Google OIDC が標準的な例として推奨される。
Project スコープ、Sync Window、Automation Policy によって権限の粒度とデプロイ時間帯を細かく制御し、リスクを最小化できる。
監査ログ取得・インシデント対応手順・バージョンアップチェックリスト を整備し、CI/CD パイプラインで RBAC 設定をコード化すれば継続的な安全性が確保できる。

これらのベストプラクティスを自社環境に組み込むことで、GitOps の高速デプロイと堅牢な権限管理を同時に実現できます。ぜひ本稿を参考に、ArgoCD の RBAC を最適化してください。

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-ArgoCD

comment コメントをキャンセル

: ArgoCD

GitOpsとブルーグリーンデプロイのKubernetes実践ガイド

GitOpsとブルーグリーン戦略の連携により、Kubernetes環境での信頼性のあるデプロイを実現。ArgoCDとArgo Rolloutsの設定手順やロールバック方法などを解説。

: ArgoCD

Argo CD RBAC設定方法とベストプラクティス

Kubernetes環境におけるArgo CDのRBAC設定をステップバイステップで解説。ConfigMap構造、Role/ClusterRole定義、ポリシー記述方法がわかります。

: ArgoCD

セルフマネージドArgoCDのカスタムヘルスチェック活用ガイド

セルフマネージド環境でのGitOps導入後、カスタムヘルスチェックが運用負荷の軽減に不可欠です。Red Hat公式ドキュメントに基づくresourceHealthChecksとCRDによるアプリケーション固有の健康状態判定手法を解説。

: ArgoCD

Kubernetes CI/CD: Argo CD vs Argo Workflow Comparison

本記事では、KubernetesベースのCI/CD自動化におけるArgo CDとArgo Workflowの比較を通じて、GitOps型デプロイや並列処理機能、ステートフルアプリケーション対応などの役割分担と適用シーンを明らかにします。

: ArgoCD

Argo CD マルチクラスタデプロイ方法 | 2026年最新ガイド

Argo CDとCluster APIの連携により、マルチクラスタ環境での自動デプロイを実現。セキュリティ対策やOpenShift独自設定まで詳しく解説します。

GitHub Actions 入門：Workflow・Job・Step・Runner と CI/CD 実装ガイド

DatabricksとSnowflakeの最新価格改定とTCO徹底比較【2026年版】

ArgoCD の RBAC 設定と最小権限設計ガイド

1. ArgoCD の RBAC 基本概念

1.1 RBAC が提供する主な機能

2. argocd-rbac-cm ConfigMap の構造と編集方法

2.1 ConfigMap の取得と保存

2.2 主なキーとフォーマット

2.3 Helm/Kustomize での上書き例

3. 最小権限ロール設計と具体的設定例

3.1 ロール別許可範囲（概要）

3.2 CSV 定義例

4. 外部認証プロバイダー（OIDC・LDAP・SAML）との連携手順

4.1 OIDC 設定例（Google）

4.2 LDAP バインド設定の要点

4.3 SAML 連携の概略手順

5. プロジェクト単位でのアクセス制御とリスク低減策

5.1 Project スコープにロールを埋め込む例

5.2 Sync Window による時間帯制御

5.3 Automation Policy で自動修復を制御

6. 監査・運用・バージョンアップ時の注意点

6.1 監査ログ取得と可視化

6.2 インシデント時のトラブルシューティング手順

6.3 バージョンアップ時の RBAC 移行チェックリスト

6.4 CI/CD パイプラインでの RBAC 自動適用例

7. 記事まとめ

2. `argocd-rbac-cm` ConfigMap の構造と編集方法