前言
最近帮某个团队做 Argo CD 的权限梳理，发现大部分团队还停留在"所有 DevOps/SRE 共享 admin 账号"的阶段。说实话，这玩意儿在 GitOps 流程里是大忌------谁做了什么、谁改了什么，全混在一起，后面出了问题根本没法追溯。
我之前也踩过这个坑：一群人用同一个 admin 账号操作，结果某天一个同学不小心把 Production 集群的 Deployment 给删了，查半天也找不到是谁干的。后来痛定思痛，开始认真搞用户管理。今天就分享一下我的实战经验，以及 Argo CD 本地用户(localuser)配置的完整流程。
先放个结论：团队超过 3 个人，就一定要做权限分离。
📝Notes: 本文假设你已经安装好了 Argo CD。
为什么需要本地用户？
很多同学第一反应是：直接上 LDAP / OIDC 单点登录不香吗？
香！当然香。但现实情况往往是：
- 团队规模不大，没有专门的 IAM 团队
- 对接企业 LDAP 的审批流程要走两个月
- 测试环境不想搞得那么复杂
这时，Argo CD 内置的本地用户机制就是最优解------轻量、灵活、开箱即用。
Argo CD 默认用户模型
Argo CD 安装完成后，只有一个内置用户：admin。它的权限是最大的，几乎所有操作都能做。
🤔 问题来了：如果团队里的开发、测试、运维都用同一个 admin 账号，你猜谁的锅？
答案很明显：出了事全是运维的锅。因为根本查不到是谁操作的。
所以我们的目标是：为不同角色创建独立用户，并赋予最小必要权限。
ConfigMap 配置本地用户：核心思路
Argo CD 的用户管理和权限配置都通过 ConfigMap 实现。具体来说：
argocd-cm: 定义用户登录名、密码哈希argocd-rbac-cm: 定义角色和权限策略
这两个 ConfigMap 修改后，Argo CD 会自动重载配置，不需要重启 Pod。这点体验还不错。
第一步：修改 argocd-cm 添加用户
先来编辑 argocd-cm ConfigMap：
bash
kubectl edit configmap argocd-cm -n argocd在 data 下添加 accounts.xxx 字段。比如我要创建一个名为 devops 的用户：
yaml
data:
accounts.devops: login
accounts.devops.enabled: "true"accounts.devops: login：允许该用户通过 UI 或 CLI 登录accounts.devops.enabled: "true"：启用该用户
📝Notes :
login表示该用户可以登录，也可以用apiKey来限制只能通过 API 访问。
第二步：设置密码
推荐用 argocd admin initial-password 或 update-password 命令生成：
bash
argocd admin initial-password --username devops --password yourpassword
# if you are managing users as the admin user, <current-user-password> should be the current admin password.
argocd account update-password \
--account <name> \
--current-password <current-user-password> \
--new-password <new-user-password>第三步：配置 RBAC 权限
光有用户还不够，还要告诉 Argo CD 这个用户能干什么。这就轮到 argocd-rbac-cm 了。
编辑它：
bash
kubectl edit configmap argocd-rbac-cm -n argocd在 data 下添加策略。我给你掰扯一下，我要让 devops 用户只管理 dev 和 staging 环境，不能碰 production：
yaml
data:
policy.default: role:readonly
policy.csv: |
p, role:devops, applications, get, dev/*, allow
p, role:devops, applications, sync, dev/*, allow
p, role:devops, applications, get, staging/*, allow
p, role:devops, applications, sync, staging/*, allow
p, role:devops, clusters, get, *, allow
p, role:devops, clusters, list, *, allow
g, devops, role:devops逐行解释：
policy.default: role:readonly：所有未被显式授权的用户默认为只读p, role:devops, applications, get, dev/*, allow：role:devops角色对dev项目下的资源有get权限p, role:devops, applications, sync, dev/*, allow：有sync权限（可以手动同步）g, devops, role:devops：把devops用户加入role:devops角色组
效果就是：devops 用户登录后，只能看到 dev 和 staging 项目，不能操作 production。✅
📝Notes: 如果想更细粒度控制，还可以限制到具体集群。比如只允许操作特定集群上的应用。
第四步：验证
用新用户登录 Argo CD UI，或者在 CLI 中：
bash
argocd login <argo-cd-url> --username devops输入密码，应该能正常登录。然后尝试访问 production 项目------你会看到 403 被拒绝。🎉
写到这里，回头看看：我的 3 条最佳实践
实操过后，总结几条经验：
1. 为每个团队创建独立用户
我推荐这么搞：
| 用户 | 团队 | 权限范围 |
|---|---|---|
devops |
运维开发 | dev / staging 项目的全量权限 |
qa |
测试团队 | 测试环境的同步权限 |
audit |
审计 | 全局只读 |
sre |
可靠性工程师 | 所有项目的全量权限 |
这样一旦出问题，直接看日志就知道是谁操作的。
2. 密码定期轮换
不要设置密码后就不管了。建议：
- 每 90 天轮换一次密码
- 使用密码管理器（如 Bitwarden / 1Password）记录
- 通过脚本批量更新
为什么要定期轮换？因为本地用户的密码是静态的，一旦泄露，攻击者就能控制你的 GitOps 流程。
📝Notes: 如果你的组织有 IAM 团队，强烈建议尽快对接 LDAP / OIDC，让密码管理集中化。
3. 权限最小化原则
别图省事给所有人都授予 admin 角色。我推荐的做法：
- 只读权限：90% 的团队成员只需要看，不需要改
- 写权限：只有 DevOps 负责人和 SRE 有
- 管理员权限：只有 1-2 个人有，用于管理用户和配置
我见过最离谱的是测试工程师有 admin 权限，然后不小心把整个 Argo CD 配置给删了------恢复起来简直噩梦。
玩点高级的：用 Helm values 管理用户配置
如果你是用 Helm 安装的 Argo CD，可以在 values.yaml 里直接配置，避免手动编辑 ConfigMap：
yaml
configs:
cm:
accounts.devops: login
accounts.devops.enabled: "true"
rbac:
policy.default: role:readonly
policy.csv: |
p, role:devops, applications, get, dev/*, allow
p, role:devops, applications, sync, dev/*, allow
g, devops, role:devops然后 helm upgrade 一下，配置就生效了。
然后再用 argocd admin initial-password 或 update-password 命令生成密码：
bash
argocd admin initial-password --username devops --password yourpassword
# if you are managing users as the admin user, <current-user-password> should be the current admin password.
argocd account update-password \
--account <name> \
--current-password <current-user-password> \
--new-password <new-user-password>总结
Argo CD 的本地用户管理机制其实不复杂，核心就是三个步骤：
- 在 ConfigMap 中定义用户（argocd-cm）
- 设置密码
- 配置 RBAC 策略（argocd-rbac-cm）
但真正重要的是权限分离和密码安全这两个意识。不要因为麻烦就用 admin 账号共享，这迟早会出事。