企业官网建设流程全解析

Argo CD 项目隔离实战指南：多团队协作的完整架构方案

【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd

多个团队共用一套 Argo CD 时，冲突几乎是必然的：业务团队误改了数据库团队的同步配置，某个应用的发布在共享命名空间里制造出撞名的资源，还有人能看见所有仓库、把任意仓库的内容同步到任意集群。这些问题的根源都一样——没有边界。Argo CD 项目隔离机制为此而生：AppProject（项目的 CRD 类型）是隔离的基本单位，它回答三个问题：谁能操作、能读哪些仓库、能部署到哪些集群和命名空间。

隔离模型全景：四大维度的边界在哪里

先看清楚这四个维度分别管什么，后面落地才不会顾此失彼：

四个维度的作用范围各管一段：

• Project 边界：AppProject 是资源的"户口"，每个 Application 必须归属一个项目，越界行为在准入阶段就被拦截。
• RBAC 策略：控制"人"，决定谁能对哪个项目、哪个应用做什么操作。
• 集群访问控制：控制"目的地"，限制项目能部署到哪些集群、哪些命名空间。
• 仓库访问控制：控制"源头"，限制项目只能从哪些 Git 仓库拉取清单。

前两者管权限，后两者管资源。RBAC 挡的是未授权的操作，资源边界挡的是有权限但超范围的操作——四道栅栏缺一不可。

RBAC 权限矩阵怎么写：argocd-rbac-cm 的三级粒度组合

Argo CD 的 RBAC 基于 Casbin 模型，全局配置放在argocd-rbac-cm这个 ConfigMap 里。策略行的格式是p, <主体>, <资源>, <动作>, <对象>, <effect>，其中资源、动作、对象三个字段正好对应三种粒度，可以任意组合收紧。

下面这段全局配置解决"两个团队权限差异大"的问题：

data: policy.csv: | # 资源级+对象级：team-alpha 只能看 my-project 下的应用 p, my-org:team-alpha, applications, get, my-project/*, allow # 操作级：只开放 sync，不给 create/delete p, my-org:team-alpha, applications, sync, my-project/*, allow # 主体绑定：team-beta 整个组挂到管理员角色 g, my-org:team-beta, role:admin # 所有认证用户的兜底角色，务必保持最小权限 policy.default: role:readonly

注意最后两行的分工：policy.csv写具体授权，policy.default只给兜底只读。一个高频误区是把大权限写进policy.default——所有认证用户至少拥有该角色，且 deny 规则无法抵消它，等于给全员发了通行证。

第二种写法是把策略下沉到项目里。AppProject 的spec.roles支持项目级角色，策略只在项目内生效，适合"一个项目、一支团队"的结构：

spec: roles: - name: developer # 对象级收窄：策略里的 my-project 前缀限定作用范围 policies: - p, role:developer, applications, get, my-project/*, allow - p, role:developer, applications, sync, my-project/*, allow # 只有这个 OIDC 组能继承 developer 角色 groups: - my-org:team-alpha:developers

从上图的授权链路看：用户先经 SSO 认证，API Server 再把用户组解析成 Casbin 主体，逐条匹配p和g规则后放行或拒绝。所以排查"某人为什么能/不能做某事"时，顺着这条链查argocd-rbac-cm和项目 roles 即可，完整字段语义可参考 docs/operator-manual/rbac.md。

动手落地：三步为一个团队创建隔离项目

假设现在要为 team-alpha 建一个独立项目，按"基础信息 → 资源白名单 → 角色分配"三步走。

第一步：基础信息。先建一个最小可运行的 AppProject，把项目容器立起来：

apiVersion: argoproj.io/v1alpha1 kind: AppProject metadata: name: my-project # 项目名，RBAC 策略中的对象前缀就是它 namespace: argocd spec: description: "team-alpha 的应用项目" displayName: "Team Alpha"

容器立起来后，它此刻还是"空房子"——任何仓库、任何集群都放得进来，接下来就要钉死资源边界。

第二步：资源白名单。用sourceRepos和destinations分别锁住源头和目的地：

spec: # 源头：只允许 team-alpha 的仓库，* 支持路径通配 sourceRepos: - https://git.example.com/team-alpha/* # 目的地：只允许默认集群的 team-alpha-* 命名空间 destinations: - namespace: team-alpha-* server: https://kubernetes.default.svc

白名单生效意味着：应用引用其他团队的仓库会直接同步失败，部署到team-beta-*也会被拒绝——这是隔离真正起作用的地方。

第三步：角色分配。项目边界只管资源，操作权限还得配 RBAC。在argocd-rbac-cm里把团队组绑到项目级角色，或直接用上面第二节的spec.roles写法，把my-org:team-alpha:developers组挂到developer角色上。两者都配置时，项目内角色策略与全局策略叠加生效。更多字段细节见 docs/user-guide/projects.md。

规模化协作进阶：标签筛选、ApplicationSet 继承与项目级同步策略

团队变多之后，隔离还要解决"可见性"和"一致性"两个问题。

标签筛选：UI 的 Apps 列表支持按项目、命名空间、标签过滤。给每个团队的应用打统一标签（如team: alpha），成员登录后只看到自己那条"泳道"，跨团队的应用不再刷屏，误操作概率也随之下降。

ApplicationSet 项目继承：ApplicationSet（批量生成 Application 的 CRD）是规模化协作的关键。基础设施团队维护共享底座、业务团队在自己的项目里引用时，App of Apps 结构能让子应用继承父应用的项目归属，生成模板里统一指定project字段即可保证"生成的应用一定落在正确的项目里"，避免 ApplicationSet 产出的应用散落在 default 项目中形成灰色地带。

项目级同步策略：同步行为（自动同步、prune、selfHeal）本身写在 Application 的spec.syncPolicy里，而不是 AppProject 里。实际落地时，用 ApplicationSet 模板按团队批量生成带统一syncPolicy的应用，就能实现"项目内同步策略一致"的效果，同时保留单个应用覆盖的余地。

运维兜底：三类审计手段确认隔离没被绕过

隔离配置完之后，运维侧需要持续验证边界是否真实生效：

1. 访问日志：API Server 的日志记录了所有 gRPC 调用与鉴权结果，argocd-server调高日志级别后，谁在什么时候请求了哪个资源、是否被 RBAC 拒绝，都能回溯。
2. 应用事件：每个 Application 的事件面板记录同步、健康检查、prune 等动作，配合kubectl get events可追踪具体一次部署触发了哪些资源变更，适合排查"谁动了我的应用"。
3. Prometheus 指标：Application Controller 暴露/metrics端点，其中argocd_app_info指标带有project、status标签，是项目维度的核心数据源。

下面这条 PromQL 直接按项目统计"未同步"应用数，出现非零值就意味着有团队的隔离部署出了问题：

# 按项目统计同步状态不是 Synced 的应用数量 count by (project) (argocd_app_info{status!="Synced"})

避坑清单与参考资料

实际落地时，这几个坑踩过的团队不在少数：

• ⚠️policy.default 误配：给它塞了带写权限的角色，全员获得兜底权限，且 deny 无法覆盖，建议自定义最小权限的role:authenticated作为默认。
• 🔒destinations 通配过宽：server: "*"加namespace: "*"等于放弃目的地边界；通配符应精确到团队命名空间前缀。
• sourceRepos 遗漏或反向过宽：新仓库没加进白名单导致同步失败，或写了根路径通配让边界形同虚设；新增仓库要同步更新项目配置。
• 集群级资源未限制：destinations只管命名空间，集群级资源（如 ClusterRole）另需clusterResourceWhitelist显式枚举，不写则默认禁止，但团队确实需要时要谨慎开通。
• 组未绑定角色：给 group 写了p策略却没有对应的g, <group>, <role>，策略完全不会生效——Casbin 要求组必须先挂角色。

完整配置参考：docs/operator-manual/argocd-rbac-cm.yaml、docs/user-guide/projects.md

• 权限闭环：RBAC 管"谁能做"，AppProject 管"能做什么"，双向拦截越权操作
• 边界显式化：仓库、集群、命名空间白名单让每团队的资源范围可枚举、可审计
• 规模化友好：ApplicationSet 统一生成项目归属与同步策略，新增团队无需重复配置
• 可观测兜底：日志、事件、指标三层审计，隔离边界被绕过时第一时间可见

【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd