3、多租户隔离模型概述：Cluster-scoped vs Namespace-scoped、RBAC、Projects 概念

在 Kubernetes 多租户环境中，Argo CD 的隔离模型决定了租户之间的资源边界与安全风险。本章从三个核心维度展开：资源作用域（Cluster-scoped vs Namespace-scoped）、访问控制（RBAC）以及逻辑分组（Projects）。理解这三者的关系，是设计安全多租户 Argo CD 架构的基础。

3.1 资源作用域：Cluster-scoped vs Namespace-scoped

Argo CD 管理的资源分为两类：集群作用域（Cluster-scoped）和命名空间作用域（Namespace-scoped）。两者的隔离能力与安全风险截然不同。

维度 Cluster-scoped Namespace-scoped
资源类型 ClusterRole、ClusterRoleBinding、CustomResourceDefinition（CRD）、Namespace、Node、PersistentVolume 等 Pod、Service、ConfigMap、Secret、Deployment、Role、RoleBinding 等
隔离粒度 粗粒度，跨命名空间甚至跨集群 细粒度，限定在单个命名空间内
安全风险 高：一个租户的误操作可能影响整个集群 低：影响范围被限制在命名空间内
Argo CD 管理方式 需要 cluster-admin 或特定 ClusterRole 权限 通过 namespace-scoped 的 Argo CD 实例或 RBAC 限制
典型场景 平台团队部署 CRD、集群级别的监控、日志采集 业务团队部署微服务、应用配置
最佳实践：在多租户架构中，应优先使用 Namespace-scoped 资源。仅当确实需要集群级能力（如安装 CRD）时，才由平台团队通过独立的 Cluster-scoped Argo CD 实例管理，并严格审计操作日志。
资源作用域对比：Cluster-scoped vs Namespace-scoped Cluster-scoped ClusterRole / ClusterRoleBinding CustomResourceDefinition (CRD) Namespace / Node / PV 风险：跨租户影响 Namespace-scoped Pod / Service / ConfigMap Deployment / StatefulSet Role / RoleBinding / Secret 风险：仅影响本命名空间 推荐：业务租户使用 Namespace-scoped，平台团队管理 Cluster-scoped

3.2 RBAC：基于角色的访问控制

Argo CD 的 RBAC 模型与 Kubernetes RBAC 紧密集成，但增加了 Argo CD 特有的角色概念。RBAC 决定了“谁”可以对“哪些资源”执行“什么操作”。

3.2.1 Argo CD RBAC 层级

  • Kubernetes RBAC（底层）：控制对 Argo CD 命名空间、ConfigMap、Secret 等资源的访问。例如，只有特定 ServiceAccount 可以读取 argocd-cm。
  • Argo CD RBAC（应用层）：通过 argocd-rbac-cm ConfigMap 定义，控制对 Application、Project、Cluster 等 Argo CD 资源的操作权限。
  • Projects RBAC（逻辑层）：在 Project 级别进一步细化，控制哪些用户/组可以操作该 Project 下的 Application。

3.2.2 内置角色与自定义策略

角色 权限范围 典型用途
role:admin 完全管理权限，包括集群管理、Project 管理、用户管理 平台管理员
role:readonly 只读权限，可查看 Application、Project 状态 审计人员、只读用户
自定义角色 通过 policy.csv 定义细粒度权限，如 p, role:dev, applications, sync, */*, allow 开发人员仅能同步特定 Project 的 Application
RBAC 策略示例（argocd-rbac-cm）： 
data:
  policy.csv: |
    p, role:dev, applications, get, */*, allow
    p, role:dev, applications, sync, project-a/*, allow
    p, role:dev, applications, delete, *, deny
    g, team-alpha, role:dev

上述策略允许 team-alpha 组的成员查看所有 Application，仅能同步 project-a 下的 Application，禁止删除任何 Application。

3.3 Projects：逻辑隔离单元

Argo CD Project 是核心的逻辑隔离边界。一个 Project 可以包含多个 Application，并定义这些 Application 可以部署到哪些目标集群和命名空间，以及允许使用哪些来源仓库。

3.3.1 Project 的核心约束

  • 源仓库约束（sourceRepos）：限制 Application 只能从指定的 Git 仓库拉取清单。
  • 目标集群约束（destinations）：限制 Application 只能部署到指定的集群和命名空间。
  • 集群资源约束（clusterResourceWhitelist/Blacklist）：控制是否允许创建集群作用域资源。
  • 命名空间资源约束（namespaceResourceWhitelist/Blacklist）：控制允许创建的命名空间资源类型。

3.3.2 多租户 Project 设计模式

模式 描述 适用场景
1 Project : 1 租户 每个租户拥有独立的 Project，完全隔离 强隔离需求，如金融、医疗
1 Project : N 租户 多个租户共享一个 Project，通过命名空间和 RBAC 区分 开发/测试环境，信任度较高的团队
分层 Project 平台级 Project + 租户级 Project，平台 Project 管理共享基础设施 大型企业，需要平台团队统一管控
Argo CD Project 多租户隔离模型 Argo CD 实例 Project: 租户A Project: 租户B Project: 平台 sourceRepos: git@github.com:team-a/* sourceRepos: git@github.com:team-b/* sourceRepos: git@github.com:platform/* App: 前端 App: 后端 App: 数据库 App: 服务A App: 服务B App: 网关 App: 监控 App: 日志 App: 告警 目标集群：cluster-prod | 目标命名空间：ns-team-a, ns-team-b, ns-platform 每个 Project 独立约束源仓库、目标集群、资源类型，实现租户隔离

3.4 三种隔离维度的协同关系

Cluster-scoped vs Namespace-scoped 定义了资源边界，RBAC 定义了用户权限，Projects 定义了逻辑分组。三者协同工作，形成完整的隔离模型：

  • 资源边界（Scope）：决定隔离的物理范围——是整个集群还是单个命名空间。
  • 访问控制（RBAC）：决定谁可以操作这些资源——用户、组、角色。
  • 逻辑分组（Projects）：决定资源如何被组织和管理——源仓库、目标集群、资源类型约束。
常见误区：仅依赖 Projects 隔离是不够的。如果 RBAC 配置不当（例如将 admin 角色授予所有用户），或者允许创建 Cluster-scoped 资源，租户仍可能越权访问其他租户的数据。必须三层同时加固。

3.5 多租户隔离模型决策矩阵

场景 资源作用域 RBAC 策略 Project 设计
开发环境（低信任） Namespace-scoped 为主 严格：每个租户仅能操作自己的命名空间 1 Project : 1 租户
测试环境（中信任） Namespace-scoped 中等：允许查看其他命名空间，但禁止修改 1 Project : N 租户
生产环境（高信任/平台管控） Namespace-scoped + 受限 Cluster-scoped 严格：仅平台团队有 Cluster-scoped 权限 分层 Project
混合环境（多集群） Namespace-scoped + 集群级 Project 约束 严格：每个集群独立 RBAC 每个集群独立 Project 或跨集群 Project
设计建议：从“最小权限”原则出发，先默认使用 Namespace-scoped + 1 Project : 1 租户模式，后续根据信任度和运维复杂度逐步放宽。始终在 argocd-rbac-cm 中记录所有自定义策略，并定期审计。
← 上一章 📖 返回目录 下一章 →