Argo CD RBAC 权限配置完全指南：从内置角色到细粒度资源授权
【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd
Argo CD 作为 Kubernetes 的声明式持续交付工具，本身并不提供用户管理系统，而是通过基于 Casbin 的 RBAC（基于角色的访问控制）机制，将外部 SSO 身份或本地用户映射到内部角色，从而精确控制对 Application、Cluster、Repository、Project 等资源的访问。本文以 docs/operator-manual/rbac.md 为主线，结合 util/rbac/rbac.go 等源码实现，系统讲解 RBAC 的模型语法、内置角色、策略匹配原理以及完整的实战配置示例，帮助你掌握从"默认只读"到"项目级细粒度授权"的完整权限治理方案。
RBAC 概述与配置载体
Argo CD 只有一个内置用户admin，它是超级用户，拥有对系统的无限制访问权限。因此，RBAC 功能必须依赖 SSO 配置 或 本地用户配置 才能发挥价值：一旦 SSO 或本地用户就绪，就可以定义额外的 RBAC 角色，并将 SSO 组或本地用户映射到这些角色上。
RBAC 配置可以在两个层面定义：
- 全局 RBAC ConfigMap：即
argocd-rbac-cm，核心文件为 argocd-rbac-cm.yaml，其中的policy.csv、policy.default、scopes、policy.matchMode等键控制全局权限； - AppProject 的角色（Project Roles）：见 docs/user-guide/projects.md，用于在项目维度内做细粒度的应用级授权，并可配合 JWT Token 使用。
从源码看，全局配置的加载由 util/rbac/rbac.go 中的RunPolicyLoader完成：它启动一个针对argocd-rbac-cmConfigMap 的 Informer（同步周期为defaultRBACSyncPeriod = 10 * time.Minute），当 ConfigMap 发生 Add/Update 事件时调用syncUpdate重新加载策略，从而实现策略热更新而无需重启 argocd-server。
基本内置角色
Argo CD 预定义了两个角色，RBAC 配置允许在此基础上扩展任意角色和组：
role:readonly：对所有资源拥有只读权限role:admin：对所有资源拥有无限制访问权限
这两个内置角色的完整定义位于仓库的 assets/builtin-policy.csv。从文件内容可以看到，role:readonly拥有对applications、applicationsets、certificates、clusters、repositories、write-repositories、projects、accounts、gpgkeys、logs等资源的get权限；role:admin则拥有全部资源的create/update/delete/sync/override/action/rollback/exec等权限，并且文件末尾的两行定义了角色继承关系：
g, role:admin, role:readonly g, admin, role:admin即role:admin自动继承role:readonly的全部权限，同时内置的admin用户被绑定到role:admin。这正是官方文档中所说"admin 是超级用户"的实现来源。
默认策略与匿名访问
policy.default：认证用户的兜底角色
当用户在 Argo CD 完成认证后，会被授予policy.default指定的角色。ConfigMap 示例 argocd-rbac-cm.yaml 中给出的默认配置为：
policy.default: role:readonly在源码 util/rbac/rbac.go 的enforce函数中，SetDefaultRole设置的角色会被优先校验：只要默认角色对请求返回allow，就直接放行。
[!WARNING]默认权限无法被 deny 规则阻断
所有已认证用户至少会获得默认策略授予的权限，这部分访问无法通过
deny规则屏蔽。官方建议创建一个最小权限的role:authenticated，再把具体权限按需授予各个角色，而不是把高权限角色直接设为默认。
匿名访问
启用匿名访问后，未认证用户将以policy.default指定的默认角色身份访问系统。可通过argocd-cmConfigMap 中的users.anonymous.enabled字段开启（见 argocd-cm.yaml）。
[!WARNING] 启用匿名访问时，建议创建一个独立的默认角色并设置
policy.default: role:unauthenticated，避免匿名用户直接获得普通已认证用户的权限。
RBAC 模型结构与语法
Argo CD 的 RBAC 模型基于 Casbin：
[request_definition] r = sub, res, act, obj [policy_definition] p = sub, res, act, obj, eft [role_definition] g = _, _ [policy_effect] e = some(where (p.eft == allow)) && !some(where (p.eft == deny)) [matchers] m = g(r.sub, p.sub) && globOrRegexMatch(r.res, p.res) && globOrRegexMatch(r.act, p.act) && globOrRegexMatch(r.obj, p.obj)这个模型揭示了两条关键规则：
- 请求元组为
sub(主体), res(资源), act(动作), obj(对象)，策略元组在此基础上多一个eft(效果)字段； - 效果判定为"存在 allow 且不存在 deny"——只要有任意一条
deny策略命中，请求即被拒绝，这与文档中"deny 优先"的描述完全一致。
组（Group）语法
组用于把已认证的用户/组分配给内部角色：
g, <user/group>, <role><user/group>：被分配角色的实体。可以是本地用户或 SSO 认证用户。使用 SSO 时，user来自 token 的federated_claims.user_id字段，组则来自 OIDC Provider 在配置的 scopes（如groups、roles）下返回的值；<role>：实体被分配到的内部角色。
策略（Policy）语法
策略用于给实体授予对特定资源的操作权限：
p, <role/user/group>, <resource>, <action>, <object>, <effect>各字段含义：
| 字段 | 含义 |
|---|---|
<role/user/group> | 策略归属的实体 |
<resource> | 执行操作的目标资源类型 |
<action> | 对资源执行的操作 |
<object> | 目标对象的标识符，格式随资源类型变化 |
<effect> | allow（放行）或deny（拒绝） |
[!NOTE]组必须先分配角色，策略才生效
想给某个组直接分配策略，必须先通过
g, <group>, <role>为该组分配一个角色，否则p, <group>, ...形式的策略不会被考虑。
资源与动作矩阵
| 资源\动作 | get | create | update | delete | sync | rollback | action | override | invoke |
|---|---|---|---|---|---|---|---|---|---|
| applications | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ |
| applicationsets | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| clusters | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| projects | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| repositories | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| accounts | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| certificates | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| gpgkeys | ✅ | ✅ | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
| logs | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| exec | ❌ | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
| extensions | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ | ✅ |
这些资源与动作常量在 util/rbac/rbac.go 中以ResourceXxx/ActionXxx常量定义，其中还包含一个未出现在表格中的write-repositories资源（内置策略中role:readonly和role:admin均对其有相应权限），用于写仓库凭据场景的独立管控。
应用级策略（Application-Specific Policy）
applications、applicationsets、logs、exec这四类资源只能在应用上下文中才具有意义。它们既可以在全局配置中设置，也可以配置在 AppProject 的角色 中。此时策略中的<object>格式为<app-project>/<app-name>。
例如，以下策略授予example-user查看所有应用的权限，但只能查看example-project项目中my-app应用的日志：
p, example-user, applications, get, *, allow p, example-user, logs, get, example-project/my-app, allow任意命名空间中的应用（Application in Any Namespaces）
当启用 Application in Any Namespace 时，<object>的格式变为<app-project>/<app-ns>/<app-name>。由于同一项目中可能出现同名应用，下面的策略确保只限制app-namespace命名空间内的访问：
p, example-user, applications, get, */app-namespace/*, allow p, example-user, logs, get, example-project/app-namespace/my-app, allowapplications 资源
applications属于应用级策略。关于update/delete动作，需要特别注意的是：
[!WARNING]glob 通配符的匹配行为
Argo CD RBAC 在评估 glob 模式时不把
/当作分隔符。因此delete/*/kind/*既能匹配delete/<group>/kind/<namespace>/<name>，也会匹配delete/<group>/<kind>/kind/<name>。通常这不是问题（资源 kind 一般含大写字母，而命名空间不含），但 kind 仍可能为小写，所以建议始终在模式中写全资源的四个部分（即始终使用四个斜杠）。
update/delete 的细粒度权限
对应用授予update或delete动作，只允许用户操作应用本身，不包含其子资源。要允许操作应用下的资源，需把动作写成<action>/<group>/<kind>/<ns>/<name>形式。
例如，只允许example-user删除prod-app应用中的 Pod：
p, example-user, applications, delete/*/Pod/*/*, default/prod-app, allow允许更新应用的所有子资源（但不允许更新应用本身）：
p, example-user, applications, update/*, default/prod-app, allow显式拒绝删除应用本身，但允许删除其 Pod：
p, example-user, applications, delete, default/prod-app, deny p, example-user, applications, delete/*/Pod/*/*, default/prod-app, allow显式允许更新应用，但拒绝更新任何子资源：
p, example-user, applications, update, default/prod-app, allow p, example-user, applications, update/*, default/prod-app, deny[!NOTE]保留旧版继承行为（自 v3.0.0 起）
v3 之前，不带
/*的update/delete动作也会作用于子资源。要保留该行为，可在argocd-cmConfigMap 中设置server.rbac.disableApplicationFineGrainedRBACInheritance: 'false'。禁用继承后，若应用本身被显式 allow，则无法再对子资源做细粒度 deny，例如下面两条策略将允许删除应用内任意资源（包括 Pod）：p, example-user, applications, delete, default/prod-app, allow p, example-user, applications, delete/*/Pod/*, default/prod-app, deny
action 动作
action动作对应两类操作：仓库内 resource_customizations 中定义的内置资源自定义动作，或你自定义的 Custom Resource Actions。<action>的格式为action/<group>/<kind>/<action-name>。
例如，资源自定义路径resource_customizations/extensions/DaemonSet/actions/restart/action.lua对应动作路径action/extensions/DaemonSet/restart；若资源不在任何 group 下（如 Pod、ConfigMap），则路径为action//Pod/action-name。
下面的策略允许用户对 DaemonSet 执行任意动作，以及对 Pod 执行maintenance-off动作：
p, example-user, applications, action//Pod/maintenance-off, default/*, allow p, example-user, applications, action/extensions/DaemonSet/*, default/*, allow允许执行任意动作：
p, example-user, applications, action/*, default/*, allowrollback 动作
rollback动作允许将应用回滚到之前同步过的版本。相比sync，它有以下限制：
- 只能回滚到应用 revision history 中的版本（上限为配置的
revisionHistoryLimit）； - 自动同步（auto-sync）启用时不能回滚；
- 支持
dryRun和prune选项，但不能覆盖其他同步选项； - 不能针对特定资源做部分同步。
回滚权限是 opt-in 的，默认关闭以保持向后兼容。启用方式是在argocd-cm中设置：
server.rbac.rollback.enforce.enable: 'true'关闭时（默认），回滚操作继续使用sync权限检查，现有策略无需改动即可工作。开启后，之前依赖sync权限执行回滚的用户需要被显式授予rollback权限。
示例——允许开发者在 dev 项目回滚应用：
p, developer, applications, rollback, dev-project/*, allow允许发布团队回滚指定应用：
p, release-team, applications, rollback, prod-project/critical-app, allow p, release-team, applications, rollback, prod-project/api-service, allowoverride 动作
override权限允许在同步Application时传入任意清单或不同的 revision，常用于开发或测试。注意：这允许用户完全更改/删除应用已部署的资源。
sync权限：把集群对象同步到Application对象定义的目标状态；override权限：允许用户把任意本地清单同步到应用上，这些清单会取代配置的源，直到下次同步。执行 override 同步后，应用大概率会处于 OutOfSync 状态；- auto-sync 启用时不能执行 override 同步。
v3.2 新增：当在argocd-cm中设置application.sync.requireOverridePrivilegeForRevisionSync: 'true'时，同步时传入 revision 也会被视为 override 操作，以防止同步到Application对象给定 revision 之外的任意版本。该标志默认false，以避免破坏现有安装；官方建议将其设为true，并只在 AppProject 维度把override权限授予确实需要的用户。
applicationsets 资源
applicationsets属于应用级策略。ApplicationSets 提供声明式的方式自动创建/更新/删除 Application。授予create动作虽然不能让用户直接创建 Application，但可以通过 ApplicationSet 间接创建。
[!NOTE] v2.5 中，无法通过 API（以及 CLI）创建带模板化 Project 字段（如
project: {{path.basename}}）的 ApplicationSet。禁止模板化项目可保证基于项目的 RBAC 限制安全有效。
由于 ApplicationSet 本身不属于任何项目，其策略<object>（<app-project>/<app-name>）中的<app-project>表示该 ApplicationSet能在哪些项目中创建 Application。下面的策略使dev-group用户无法创建能够在dev-project之外创建应用的 ApplicationSet：
p, dev-group, applicationsets, *, dev-project/*, allowlogs 资源
logs属于应用级策略。授予get动作后，用户可通过 Argo CD UI 查看应用的 Pod 日志，功能类似kubectl logs。
exec 资源
exec属于应用级策略。授予create动作后，用户可通过 Argo CD UI 进入应用的 Pod 执行命令，功能类似kubectl exec。更多信息见 Web-based Terminal。
extensions 资源
extensions资源用于配置调用 Proxy Extensions 的权限。extensions的 RBAC 校验与applications资源协同工作：用户必须对请求来源的应用拥有读权限。下面的示例允许example-user在default项目下所有应用中调用httpbin扩展：
p, example-user, applications, get, default/*, allow p, example-user, extensions, invoke, httpbin, allowclusters 资源
clusters资源控制用户通过 Argo CD API/UI/CLI 列出、创建、更新或删除集群条目。注册的集群凭据通常以 Kubernetes Secret 形式存储在 Argo CD 命名空间中（带argocd.argoproj.io/secret-type: cluster标签），这些 Secret 可携带project字段将集群限定到单个 AppProject。
clusters策略的<object>派生自集群 Secret 的server字段（API URL，如https://kubernetes.default.svc）及其可选的project字段，实现函数为 server/cluster/cluster.go 中的CreateClusterRBACObject：
- 未限定项目的集群（Secret 的
project为空）：object 即集群 server URL，如https://kubernetes.default.svc； - 限定项目的集群（Secret 的
project已设置）：object 为<project>/<server-url>，如my-project/https://api.example.com:6443。
示例：
# 让默认角色可见未限定的集群内条目 p, role:defaultrole, clusters, get, https://kubernetes.default.svc, allow # 授予某角色对限定项目的外部集群的完整权限 p, role:my-role, clusters, *, my-project/https://api.example.com:6443, allow由于policy.matchMode默认为glob，支持通配符：
# 任何已认证用户可 get "my-project" 拥有的所有集群 Secret p, role:defaultrole, clusters, get, my-project/*, allow[!NOTE]集群名称不能作为 RBAC object
clusters策略的<object>必须是集群 server URL（可带项目前缀）。集群的逻辑name字段（声明式集群 Secret 中的data.name/stringData.name）不是合法的 object 格式。例如p, ..., clusters, get, my-cluster, allow无法匹配 server 为https://api.example.com:6443的集群。关于如何为集群 Secret 附加
project并让开发者向项目内自助注册集群，见 Project scoped Repositories and Clusters。
deny 效果
当策略使用deny效果且策略匹配时，它会生效。即使有更具体的allow策略同时匹配，deny仍然具有更高优先级。策略在策略文件中的出现顺序不影响结果，评估结果具有确定性。这一语义正是 assets/model.conf 中策略效果表达式some(where (p.eft == allow)) && !some(where (p.eft == deny))的体现。
策略评估与匹配
访问评估分两个阶段：先校验默认策略配置，再校验当前用户的策略。
- 如果默认策略已经 allow 或 deny 了某操作，该结果直接生效，不再继续评估；
- 当默认策略效果未定义时，继续按"用户本身 → 用户所属的每个组"的顺序评估主体相关策略。
匹配引擎由policy.matchMode配置，有两种模式：
glob：基于glob包（默认）；regex：基于 Go 标准库regexp包。
评估过程中，只有所有 token 都匹配时才返回效果；评估会持续到所有匹配策略评估完毕，或某条deny策略命中为止。全部策略评估后，只要存在至少一个allow且没有deny，访问即被授予。从源码看，匹配函数通过AddFunction("globOrRegexMatch", ...)注入 Casbin 模型（util/rbac/rbac.go 的tryGetCasbinEnforcer），glob 模式下使用globMatchFunc调用glob.Match。
glob 匹配细节
使用glob模式时，策略 token 被当作无分隔符的单一术语处理。考虑策略：
p, example-user, applications, action/extensions/*, default/*, allow当example-user执行extensions/DaemonSet/test动作时，会发生以下匹配：
- 当前用户
example-user匹配 tokenexample-user； - 值
applications匹配 tokenapplications； - 值
action/extensions/DaemonSet/test匹配action/extensions/*（/不被当作分隔符，因此无需使用**）； - 值
default/my-app匹配default/*。
[!TIP] 关于 glob 模式匹配的性能调优，可参考 High Availability - argocd-server 中的
server.glob.cache.size配置键。源码中 util/glob/glob.go 使用 LRU 缓存已编译的 glob 模式（默认DefaultGlobCacheSize = 10000个条目），argocd-cmd-params-cm的server.glob.cache.size（或 server 的--glob-cache-size启动参数）可调整该缓存大小。
使用 SSO 用户/组
scopes字段控制 RBAC 强制时检查哪些 OIDC scopes（除subscope 外）。省略时默认值为'[groups]'，值可以是字符串或字符串列表。更多信息见 User Management Documentation。
下面的示例同时提取 OIDC Provider 的email和groups，并演示了显式角色绑定与角色继承：
apiVersion: v1 kind: ConfigMap metadata: name: argocd-rbac-cm namespace: argocd labels: app.kubernetes.io/name: argocd-rbac-cm app.kubernetes.io/part-of: argocd data: policy.csv: | p, my-org:team-alpha, applications, sync, my-project/*, allow g, my-org:team-beta, role:admin g, user@example.org, role:admin g, admin, role:admin g, role:admin, role:readonly policy.default: role:readonly scopes: '[groups, email]'这里：
g, admin, role:admin将内置 admin 用户显式绑定到 admin 角色；g, role:admin, role:readonly演示了角色继承：任何被授予role:admin的用户自动拥有role:readonly的全部权限。
这种方式可以与 AppProject 结合，把用户的 email 和组直接关联到项目层面：
apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: team-beta-project namespace: argocd spec: roles: - name: admin description: Admin privileges to team-beta policies: - p, proj:team-beta-project:admin, applications, *, team-beta-project/*, allow groups: - user@example.org # Value from the email scope - my-org:team-beta # Value from the groups scope本地用户/账号
本地用户 通过把用户加入角色或直接分配策略来获得访问权限。
直接给本地用户分配策略：
p, my-local-user, applications, sync, my-project/*, allow把本地用户加入角色：
g, my-local-user, role:admin[!WARNING]组名歧义风险
如果启用了 SSO，任何 scope 与本地用户同名的 SSO 用户都会被加入与本地用户相同的角色。例如本地用户
sally被加入role:admin，而某个 SSO 用户的 scope 恰好也叫sally，则该 SSO 用户也会获得role:admin。典型风险场景：SSO Provider 是 SCM（源码管理平台），组织成员会自动获得以组织名命名的 scope。用户若能创建/加入组织，就可能获得同名本地用户的权限。
为避免歧义，同时使用本地用户与 SSO 时，建议直接给本地用户分配策略，而不是给本地用户分配角色。也就是说，用下面的显式策略代替
g, my-local-user, role:admin：p, my-local-user, *, *, *, allow
策略 CSV 组合（Policy CSV Composition）
可以在argocd-rbac-cmConfigMap 中提供额外的条目来组合最终的策略 CSV。键必须符合policy.<任意字符串>.csv模式。Argo CD 会把这些额外策略按 key 字符串顺序拼接在主策略（policy.csv）之下。
例如提供了policy.A.csv和policy.B.csv两个额外策略时，会先拼接policy.A.csv再拼接policy.B.csv。这非常适合在 Kustomize、Helm 等配置管理工具中组合策略。
从源码看，util/rbac/rbac.go 的PolicyCSV函数正是实现这一逻辑：它先写入policy.csv，再对所有 key 排序，将匹配policy.前缀与.csv后缀的键按序追加。
下面的示例展示如何在 Kustomize overlay 中通过 patch 向现有 RBAC ConfigMap 添加额外配置：
apiVersion: v1 kind: ConfigMap metadata: name: argocd-rbac-cm namespace: argocd data: policy.tester-overlay.csv: | p, role:tester, applications, *, */*, allow p, role:tester, projects, *, *, allow g, my-org:team-qa, role:tester完整 ConfigMap 参考
下面是一个完整的argocd-rbac-cm配置示例（参考 argocd-rbac-cm.yaml），涵盖了各核心键：
apiVersion: v1 kind: ConfigMap metadata: name: argocd-rbac-cm namespace: argocd labels: app.kubernetes.io/name: argocd-rbac-cm app.kubernetes.io/part-of: argocd data: # policy.csv 是用户自定义 RBAC 策略与角色定义文件（可选） # 策略规则格式: p, subject, resource, action, object, effect # 角色定义与绑定格式: g, subject, inherited-subject policy.csv: | # 授予 'my-org:team-alpha' 组所有成员在 'my-project' 中同步应用的权限 p, my-org:team-alpha, applications, sync, my-project/*, allow # 授予 'my-org:team-beta' 所有成员 admin 角色 g, my-org:team-beta, role:admin # 额外的策略条目，key 必须符合 'policy.<any string>.csv' 模式， # Argo CD 会将其拼接在主策略（policy.csv）之下 policy.overlay.csv: | p, role:tester, applications, *, */*, allow p, role:tester, projects, *, *, allow g, my-org:team-qa, role:tester # policy.default 是授权时兜底的默认角色（可选） # 省略或为空时，用户仍可登录，但看不到任何应用、项目等 policy.default: role:readonly # scopes 控制 RBAC 强制时检查的 OIDC scopes（除 sub scope 外） # 省略时默认为 '[groups]'，值可以是字符串或字符串列表 scopes: '[cognito:groups, email]' # matchMode 配置 casbin 的匹配函数，'glob' 或 'regex' # 省略或配置错误时默认为 'glob' policy.matchMode: 'glob'补充说明：argocd-rbac-cm.yaml是 CSV 策略文件，Argo CD 解析时会忽略以#开头的行，因此支持行注释。
验证与测试 RBAC 策略
argocd admin settings rbac命令（见 argocd_admin_settings_rbac.md）用于验证策略。该工具可以测试某个角色或主体能否针对尚未上线的策略（来自本地文件或 ConfigMap）执行请求动作，也可以针对集群中 Argo CD 正在使用的实时RBAC 配置进行测试。
验证策略
使用argocd admin settings rbac validate命令（见 argocd_admin_settings_rbac_validate.md）检查新策略配置是否合法、能否被 Argo CD 的 RBAC 实现正确理解。与之对应的源码是 util/rbac/rbac.go 的ValidatePolicy函数：它用 Casbin 解析策略字符串并检查语法错误，同时通过CheckUserDefinedRoleReferentialIntegrity检查角色引用完整性（即每个定义的角色都必须能在策略中找到对应的 subject）。
测试策略
使用argocd admin settings rbac can命令（见 argocd_admin_settings_rbac_can.md）测试某个角色或主体（组或本地用户）是否拥有对特定资源执行特定操作的足够权限。
结合 AppProject 的完整实战
最后给出一个完整的实战组合：全局 RBAC 控制跨项目权限，AppProject 角色控制项目内权限。下面的 AppProject 为my-oidc-group组成员提供项目内所有应用的只读权限（完整示例见 docs/user-guide/projects.md）：
apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project namespace: argocd spec: roles: # 提供项目内所有应用只读权限的角色 - name: read-only description: Read-only privileges to my-project policies: - p, proj:my-project:read-only, applications, get, my-project/*, allow groups: - my-oidc-group关键点：项目角色策略中的角色名必须遵循proj:<project-name>:<role-name>模式，否则在 Argo CD 授权过程中不生效。Argo CD 运行时会基于角色名动态创建组，上述定义会生成以下 Casbin 规则：
p, proj:my-project:read-only, applications, get, my-project/*, allow g, my-oidc-group, proj:my-project:read-only项目角色的管理可通过 CLI 完成：
argocd proj role list argocd proj role get argocd proj role create argocd proj role delete argocd proj role add-policy argocd proj role remove-policy项目角色本身离不开 JWT Token 的配合（Token 与角色的策略绑定，策略变更立即生效）：
argocd proj role create-token PROJECT ROLE-NAME argocd proj role delete-token PROJECT ROLE-NAME ISSUED-ATJWT Token 不在 Argo CD 中存储，只能在创建时获取，可通过 CLI 的--auth-token参数或ARGOCD_AUTH_TOKEN环境变量使用，直到过期或被吊销。
关键源码速查
- 模型定义：assets/model.conf —— Casbin 模型、匹配器与 deny 优先的效果表达式；
- 内置策略：assets/builtin-policy.csv ——
role:readonly、role:admin及admin用户绑定； - RBAC 执行器：util/rbac/rbac.go —— 策略加载、ConfigMap Informer 热更新、
PolicyCSV组合、ValidatePolicy校验、glob/regex 匹配注入； - glob 缓存：util/glob/glob.go —— 编译模式 LRU 缓存（默认 10000 条，可通过
server.glob.cache.size调整）； - 集群对象构造：server/cluster/cluster.go ——
CreateClusterRBACObject生成clusters策略 object； - 配置示例：argocd-rbac-cm.yaml 与 argocd-cm-yaml.md；
- 项目角色：docs/user-guide/projects.md。
【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
