企业官网建设流程全解析

前言

当 ArgoCD 管理多个团队的应用时，权限隔离是必须的——A 团队不能看到或操作 B 团队的应用，开发者不能修改生产配置。本篇从零配置 ArgoCD 的 RBAC 和 SSO，实现企业级多租户。

一、ArgoCD 认证体系

认证（Authentication）: 你是谁？ - 本地用户（admin 和手动创建的用户） - SSO（GitHub/GitLab/Google/LDAP/OIDC） 授权（Authorization）: 你能做什么？ - RBAC 策略 - AppProject 限制

认证方式对比

二、配置 SSO（以 GitHub 为例）

注册 OAuth App

GitHub → Settings → Developer settings → OAuth Apps → New OAuth App Application name: ArgoCD Homepage URL: https://argocd.mycompany.com Authorization callback URL: https://argocd.mycompany.com/api/dex/callback → 记录 Client ID 和 Client Secret

配置 Dex

# argocd-cm ConfigMap apiVersion: v1 kind: ConfigMap metadata: name: argocd-cm namespace: argocd data: url: https://argocd.mycompany.com # Dex 配置 dex.config: | connectors: - type: github id: github name: GitHub config: clientID: $GITHUB_CLIENT_ID clientSecret: $GITHUB_CLIENT_SECRET orgs: - name: myorg # 组织名 teams: - devops-team # 团队名 - team-alpha - team-beta # 加载所有团队（不只是上面列出的） loadAllGroups: false # 团队名映射 teamNameField: slug

在 Secret 中存储 OAuth 凭据

# 更新 argocd-secret kubectl create secret generic argocd-secret \ -n argocd \ --from-literal=github.clientID=$GITHUB_CLIENT_ID \ --from-literal=github.clientSecret=$GITHUB_CLIENT_SECRET \ --dry-run=client -o yaml | kubectl apply -f - # 重启 Dex Server kubectl rollout restart deployment argocd-dex-server -n argocd

登录后看到的身份

SSO 登录后，用户身份为: org:myorg:team:devops-team → 对应 GitHub 组织 myorg 下的 devops-team org:myorg:team:team-alpha → 对应 team-alpha 团队

三、RBAC 策略配置

策略语法

p, <role/user/group>, <resource>, <action>, <project/application>, <allow/deny> 示例: p, role:admin, applications, *, */*, allow → admin 可以操作所有应用 p, role:viewer, applications, get, */*, allow → viewer 只能查看 p, org:myorg:team:team-alpha, applications, *, team-alpha/*, allow → team-alpha 可以操作自己的应用

资源和操作

RBAC ConfigMap

apiVersion: v1 kind: ConfigMap metadata: name: argocd-rbac-cm namespace: argocd data: # 默认策略（未匹配到任何规则的用户） policy.default: role:readonly # 详细策略 policy.csv: | # === 角色定义 === # 全局管理员 p, role:admin, applications, *, */*, allow p, role:admin, clusters, *, *, allow p, role:admin, repositories, *, *, allow p, role:admin, projects, *, *, allow p, role:admin, accounts, *, *, allow # 只读用户 p, role:readonly, applications, get, */*, allow p, role:readonly, clusters, get, *, allow p, role:readonly, repositories, get, *, allow p, role:readonly, projects, get, *, allow # team-alpha 团队 p, role:team-alpha, applications, *, team-alpha/*, allow p, role:team-alpha, projects, get, team-alpha, allow p, role:team-alpha, applications, sync, team-alpha/*-prod, deny # team-alpha 可以管理自己的应用，但不能同步生产 # team-beta 团队 p, role:team-beta, applications, *, team-beta/*, allow p, role:team-beta, projects, get, team-beta, allow # === 角色绑定 === # GitHub 团队 → ArgoCD 角色 g, org:myorg:team:devops-team, role:admin g, org:myorg:team:team-alpha, role:team-alpha g, org:myorg:team:team-beta, role:team-beta # 本地用户 → 角色 g, alice, role:admin g, bob, role:readonly

培训要点：RBAC 策略中deny优先于allow。即使前面的规则 allow 了，后面的 deny 仍然可以阻止。利用这一点可以给某个角色开了权限但禁掉特定操作。

四、AppProject 权限隔离

创建团队 Project

# team-alpha 的 Project apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: team-alpha namespace: argocd spec: description: Team Alpha applications # 允许的 Git 仓库 sourceRepos: - https://github.com/myorg/team-alpha-* - https://github.com/myorg/shared-deploy # 允许的目标 destinations: # 只能部署到 team-alpha- 开头的命名空间 - server: https://kubernetes.default.svc namespace: team-alpha-* # 可以部署到共享的 dev 命名空间 - server: https://kubernetes.default.svc namespace: shared-dev # 允许的集群 sourceNamespaces: - team-alpha-dev - team-alpha-test # 允许的资源类型 namespaceResourceWhitelist: - group: '*' kind: '*' # 禁止的资源类型 namespaceResourceBlacklist: - group: '' kind: ResourceQuota # 不允许创建 ResourceQuota - group: '' kind: LimitRange # 集群资源白名单（如 Namespace） clusterResourceWhitelist: - group: '' kind: Namespace # 同步窗口 syncWindows: - kind: allow schedule: '0 9 * * 1-5' duration: 12h applications: - '*' manualSync: true - kind: deny schedule: '0 0 * * 0,6' # 周末禁止同步 duration: 48h applications: - '*-prod' manualSync: false # 角色定义（配合 RBAC） roles: - name: developer description: Team Alpha developers policies: - p, proj:team-alpha:developer, applications, get, team-alpha/*, allow - p, proj:team-alpha:developer, applications, sync, team-alpha/*-dev, allow - p, proj:team-alpha:developer, applications, sync, team-alpha/*-prod, deny groups: - org:myorg:team:team-alpha - name: lead description: Team Alpha leads policies: - p, proj:team-alpha:lead, applications, *, team-alpha/*, allow groups: - org:myorg:team:team-alpha-leads

Application 关联 Project

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: myapp-prod namespace: argocd spec: project: team-alpha # 关联到 team-alpha 项目 source: repoURL: https://github.com/myorg/team-alpha-myapp-deploy.git path: overlays/prod destination: server: https://kubernetes.default.svc namespace: team-alpha-myapp-prod

五、多租户最佳实践

1. 每个团队一个 Project

AppProject: team-alpha → 限制到 team-alpha-* 命名空间 team-beta → 限制到 team-beta-* 命名空间 platform → 可以操作 kube-system 等基础设施命名空间

2. SSO Group → Project Role 映射

GitHub Teams: myorg:devops-team → ArgoCD role:admin myorg:team-alpha → AppProject team-alpha role:developer myorg:team-beta → AppProject team-beta role:developer

3. 生产环境额外保护

# 生产应用不允许自动同步，必须手动审批 spec: project: team-alpha syncPolicy: # 不配置 automated → 手动同步 syncOptions: - CreateNamespace=true # 配合同步窗口限制时间

4. 审计日志

# 查看 ArgoCD 操作日志 kubectl logs -n argocd -l app.kubernetes.io/name=argocd-server | grep "GRPC" # 查看 Application 变更事件 kubectl get events -n argocd --field-selector reason=ApplicationSync # 定期导出审计日志 argocd admin settings rbac can --policy-file rbac-policy.csv \ role:team-alpha applications sync team-alpha/myapp-prod # 输出: yes / no

六、本篇要点回顾

1. 认证用 SSO（GitHub/GitLab/OIDC），不推荐本地用户管理大量用户
2. RBAC 策略语法：p, <subject>, <resource>, <action>, <object>, <allow/deny>
3. deny 优先于 allow，可用于"开了权限但禁特定操作"
4. AppProject 限制仓库、命名空间、资源类型、同步窗口
5. SSO Group → Project Role 映射实现团队隔离
6. 生产环境：手动同步 + 同步窗口 + 禁止自动同步

下一篇预告：《健康检查与资源钩子：自定义健康状态》——从权限进入运维，学习如何让 ArgoCD 更智能地判断应用健康状态。