📚 课程目录第3章项目（Project）概念

3、项目（Project）概念：项目的作用、项目级资源配置、项目级RBAC、项目与Application的关系

3.1 项目（Project）的核心作用

在 Argo CD 中，Project 是逻辑隔离与多租户治理的基石。它并非 Kubernetes 原生的 Namespace，而是 Argo CD 自身定义的 CRD（Custom Resource Definition），用于对 Application 进行分组、约束和授权。项目解决了多团队、多环境共享同一个 Argo CD 实例时的资源冲突与安全边界问题。

  核心作用总结：
  资源边界：限制 Application 可以部署到哪些目标 Kubernetes 集群和 Namespace。
来源约束：控制允许从哪些 Git 仓库、Helm Chart 仓库拉取配置。
权限隔离：通过项目级 RBAC 实现不同团队只能操作属于自己的 Application。
准入策略：作为后续章节（如 Config Management Plugin、Sync Waves）的挂载点，统一管控部署行为。

3.2 项目级资源配置

每个 Project 通过 spec 字段定义一组白名单规则，约束其下所有 Application 的行为。以下是关键资源配置项：

配置字段	作用域	说明
`sourceRepos`	来源仓库	允许的 Git/Helm 仓库 URL 列表，支持通配符（如 `https://github.com/my-org/*`）
`destinations`	目标集群	允许部署的目标集群 URL 和 Namespace 组合，格式为 `server: namespace`
`clusterResourceWhitelist`	集群资源	允许创建的集群级别资源（如 Namespace、ClusterRole），通常严格限制
`namespaceResourceBlacklist`	命名空间资源	禁止创建的 Namespace 级别资源类型（如 `NetworkPolicy`）
`orphanedResources`	资源清理	是否监控并警告/自动清理 Argo CD 不再管理的资源
`syncWindows`	同步窗口	定义允许或禁止自动同步的时间段，用于生产环境变更管控

# 示例：一个典型的生产项目配置片段
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production
spec:
  sourceRepos:
  - 'https://gitlab.internal.com/team-a/*'
  destinations:
  - namespace: 'prod-*'
    server: 'https://kubernetes.default.svc'
  - namespace: 'prod-*'
    server: 'https://cluster-eu-west-1.internal:6443'
  clusterResourceWhitelist:
  - group: ''
    kind: 'Namespace'
  namespaceResourceBlacklist:
  - group: 'rbac.authorization.k8s.io'
    kind: 'ClusterRoleBinding'
  orphanedResources:
    warn: true
  syncWindows:
  - applications:
    - '*-critical'
    schedule: '0 22 * * *'
    duration: '8h'
    kind: 'deny'
    manualSync: true

最佳实践： 生产项目应始终设置 clusterResourceWhitelist 为最小权限，并开启 orphanedResources.warn: true 来发现意外残留的资源。

3.3 项目级 RBAC

Argo CD 的 RBAC 模型分为两层：全局 RBAC（基于 argocd-rbac-cm ConfigMap）和 项目级 RBAC（基于 Project 的 roles 字段）。项目级 RBAC 允许更细粒度的权限委派，无需修改全局配置。

项目级 RBAC 通过 spec.roles 定义，每个角色包含一组 policies（Casbin 格式策略）。

# 项目级 RBAC 示例
spec:
  roles:
  - name: developer
    description: "Team A developers - read-only access"
    policies:
    - p, proj:production:developer, applications, get, production/*, allow
    - p, proj:production:developer, applications, sync, production/*, deny
    groups:
    - team-a-developers
  - name: admin
    description: "Team A admins - full control"
    policies:
    - p, proj:production:admin, applications, *, production/*, allow
    groups:
    - team-a-admins

策略格式遵循 Casbin 标准：[p|g, subject, resource, action, object, effect]。其中 proj:production:developer 是自动生成的 RBAC 主体名称，格式为 proj:<project-name>:<role-name>。

角色类型	典型权限	适用场景
viewer	get、list	只读查看 Application 状态
developer	get、sync、override	触发同步、修改参数，但不能删除
admin	*（所有操作）	完全管理项目下的 Application

注意： 项目级 RBAC 仅控制对 该项目下 Application 的访问。全局资源（如 Cluster、Repository、Project 本身）仍由全局 RBAC 控制。不要将项目级 RBAC 与全局 RBAC 混淆。

3.4 项目与 Application 的关系

Application 是 Argo CD 的工作负载单元，而 Project 是 Application 的 容器与策略载体。每个 Application 必须属于且仅属于一个 Project（默认项目名为 default）。

关系模型可以概括为：

一对多：一个 Project 可以包含多个 Application。
强制绑定：Application 的 spec.project 字段指定所属项目，创建后不可更改（除非删除重建）。
策略继承：Application 在同步时自动继承其所属 Project 的 sourceRepos、destinations、syncWindows 等约束。
权限隔离：用户通过项目级 RBAC 只能操作其有权限的项目下的 Application。

# Application 引用 Project 的示例
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: production   # 必须引用已存在的 Project
  source:
    repoURL: 'https://gitlab.internal.com/team-a/guestbook.git'
    path: helm-guestbook
    targetRevision: HEAD
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: prod-guestbook

3.5 项目级准入策略的通信机制预览

项目不仅是配置容器，更是 准入策略的通信枢纽。在后续章节中，我们将深入探讨：

Project 如何通过 spec.sourceRepos 与 Git Webhook 联动，触发准入校验。
Project 的 syncWindows 如何与 Argo CD 的同步引擎通信，实现变更窗口控制。
项目级 RBAC 策略如何与外部 OIDC/OAuth 身份提供商集成，实现细粒度权限传递。

预习要点： 理解 Project 的资源配置和 RBAC 模型，是掌握后续“准入策略通信机制”的基础。请确保你能独立编写一个包含 sourceRepos、destinations 和 roles 的完整 Project YAML。