3. 多租户隔离基础：Namespace 隔离、RBAC 配置、Project 资源隔离、AppProject 的作用

在云原生环境中，多租户隔离是保障安全与合规的基石。Argo CD 作为 GitOps 的核心组件，其多租户能力直接决定了集群能否安全地服务于多个团队或业务线。本章将深入剖析实现多租户隔离的四个关键层次：Namespace 隔离、RBAC 配置、Project 资源隔离以及 AppProject 的作用。

3.1 四层隔离模型总览

多租户隔离并非单一维度的操作，而是一个从底层基础设施到上层应用策略的立体架构。下表总结了四个层次的核心职责与隔离粒度：

3.2 Namespace 隔离：第一道物理防线

Namespace 是 Kubernetes 内置的隔离机制。在多租户场景下，每个租户（团队、项目或业务线）通常拥有一个或多个专属 Namespace。Namespace 隔离主要解决以下问题：

• 资源名称冲突： 不同租户可以创建同名的 Service、ConfigMap 或 Secret，互不干扰。
• 网络策略基础： 结合 NetworkPolicy，可以限制跨 Namespace 的 Pod 通信，实现网络层面的租户隔离。
• 资源配额管理： 通过 ResourceQuota 和 LimitRange，限制每个 Namespace 的 CPU、内存、存储等资源消耗，防止“吵闹邻居”问题。

# 示例：为租户 team-alpha 创建隔离的 Namespace
apiVersion: v1
kind: Namespace
metadata:
  name: team-alpha
  labels:
    tenant: alpha
    environment: production
---
# 示例：为 team-alpha 设置资源配额
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-alpha-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    persistentvolumeclaims: "5"

3.3 RBAC 配置：精细化权限控制

仅有 Namespace 隔离是不够的，必须配合 RBAC 确保只有授权用户才能操作对应 Namespace 内的资源。在多租户 Argo CD 环境中，RBAC 配置分为两个层面：

1. Kubernetes RBAC： 控制用户或 ServiceAccount 对集群资源（Pod、Deployment、Service 等）的访问权限。
2. Argo CD RBAC： 控制用户对 Argo CD 自身资源（Application、AppProject、Repository 等）的访问权限。

典型的租户 RBAC 配置模式如下：

# Kubernetes RBAC：授予 team-alpha 管理员对其 Namespace 的完全控制权
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-alpha-admin-binding
  namespace: team-alpha
subjects:
- kind: User
  name: "alice@team-alpha.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: rbac.authorization.k8s.io
---
# Argo CD RBAC：限制 alice 只能管理 team-alpha 相关的 Application 和 Project
# 在 argocd-rbac-cm ConfigMap 中配置
data:
  policy.csv: |
    p, role:team-alpha-admin, applications, *, team-alpha/*, allow
    p, role:team-alpha-admin, projects, get, team-alpha, allow
    g, alice@team-alpha.com, role:team-alpha-admin

3.4 Project 资源隔离：Argo CD 的逻辑边界

在 Argo CD 中，Project（即 AppProject）是资源隔离的核心单元。一个 Project 可以包含多个 Application，并定义这些 Application 可以部署到哪些目标集群和 Namespace。Project 资源隔离的关键配置包括：

• sourceRepos： 允许从哪些 Git 仓库拉取清单。
• destinations： 允许部署到哪些目标集群（cluster URL）和 Namespace。
• clusterResourceWhitelist/Blacklist： 控制是否允许创建集群级别的资源（如 Namespace、ClusterRole）。
• namespaceResourceWhitelist/Blacklist： 控制允许在目标 Namespace 内创建哪些 Kubernetes 资源类型。

# 示例：为 team-alpha 创建 AppProject，限制其只能部署到自己的 Namespace
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-alpha
  namespace: argocd
spec:
  sourceRepos:
  - 'https://git.internal.company.com/team-alpha/*'
  destinations:
  - namespace: team-alpha
    server: https://kubernetes.default.svc
  - namespace: team-alpha-staging
    server: https://kubernetes.default.svc
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace
  namespaceResourceBlacklist:
  - group: 'rbac.authorization.k8s.io'
    kind: 'ClusterRoleBinding'
  - group: 'rbac.authorization.k8s.io'
    kind: 'ClusterRole'

3.5 AppProject 的作用：策略与合规的入口

AppProject 不仅仅是资源隔离的容器，它更是 Argo CD 中策略引擎的入口点。通过 AppProject，平台团队可以注入全局性的合规策略和安全检查。AppProject 的核心作用可以归纳为以下五点：

1. 绑定 RBAC： 将用户/组与 Project 关联，确保只有授权用户才能操作该 Project 下的 Application。
2. 限制部署目标： 通过 destinations 字段，防止应用部署到非授权的集群或 Namespace。
3. 注入同步策略： 可以设置自动同步策略、prune 行为、selfHeal 开关等，统一团队行为。
4. 集成策略引擎： 通过 syncPolicy 的 automated 字段或与 OPA/Kyverno 集成，在同步前执行策略检查。
5. 审计与合规： 所有通过 AppProject 部署的应用变更都会被记录，便于审计追踪。

3.6 四层隔离协作流程

下图展示了从用户请求到应用部署的完整隔离协作流程：

3.7 隔离策略对比与选择建议

在实际落地时，不同隔离层次有不同的适用场景和成本。下表可以帮助你根据团队规模和合规要求做出选择：