4. 项目级RBAC配置:在AppProject中配置sourceRepos、destinations、clusterResourceWhitelist/Blacklist

项目级RBAC是Argo CD多租户安全模型的核心防线。通过在AppProject资源中精确配置sourceRepos、destinations以及clusterResourceWhitelist/Blacklist,平台团队可以严格限定每个项目能拉取哪些Git仓库、部署到哪些目标集群/命名空间、以及允许或禁止创建哪些集群范围的资源。本节将逐一拆解这三个配置维度的语义、典型场景和评审要点。

核心原则:项目级RBAC遵循“默认拒绝,显式允许”的安全模型。未在sourceRepos中列出的仓库、未在destinations中列出的目标、未在clusterResourceWhitelist中列出的集群资源类型,均被隐式拒绝。

4.1 sourceRepos:限定可用的Git仓库来源

sourceRepos字段定义了一个项目允许从中拉取应用清单的Git仓库URL列表。任何试图引用列表之外仓库的Application或ApplicationSet都将被Argo CD拒绝。

配置方式 示例值 说明
精确匹配 https://github.com/my-org/team-a.git 只允许单个仓库
通配符匹配 https://github.com/my-org/* 允许my-org下所有仓库
多仓库列表 ['https://github.com/org/repo1.git', 'https://gitlab.com/team/repo2.git'] 显式枚举多个允许仓库
拒绝所有 [] 不允许任何外部仓库(仅用于特殊隔离项目)
安全评审要点:
  • 避免使用过于宽泛的通配符(如*),应优先使用https://github.com/your-org/*限定组织范围。
  • 禁止将私有仓库与公共仓库混用在同一项目内,防止敏感配置泄露。
  • 定期审计sourceRepos列表,移除已废弃或不再维护的仓库条目。

4.2 destinations:控制部署目标集群与命名空间

destinations字段定义了项目允许将应用部署到哪些Kubernetes集群和命名空间。每个目标条目由serverURL(或name)和namespace组成。

# 典型destinations配置示例
destinations:
  - serverURL: https://kubernetes.default.svc
    namespace: team-a-prod
  - serverURL: https://kubernetes.default.svc
    namespace: team-a-staging
  - serverURL: https://cluster-2.example.com:6443
    namespace: "*"  # 允许该集群的所有命名空间(需谨慎)
字段 允许值 安全建议
serverURL 集群API Server URL 或 https://kubernetes.default.svc(本地集群) 优先使用精确URL,避免使用*通配所有集群
namespace 具体命名空间名称 或 * 仅当团队完全信任时才使用*;推荐显式列出每个命名空间
name 集群名称(替代serverURL) 需确保集群名称在Argo CD中唯一且不冲突
最佳实践:为每个项目创建独立的命名空间(如team-a-prod、team-a-staging),并在destinations中精确列出这些命名空间。这可以防止团队A的应用意外部署到团队B的命名空间中。

4.3 clusterResourceWhitelist / Blacklist:集群范围资源的准入控制

这两个字段控制项目是否允许创建、更新或删除集群范围的资源(如ClusterRole、ClusterRoleBinding、PersistentVolume、Namespace、CustomResourceDefinition等)。

  • Whitelist(白名单)模式:只允许列表中显式列出的集群资源类型。未列出的类型将被拒绝。推荐用于多租户隔离场景。
  • Blacklist(黑名单)模式:禁止列表中列出的集群资源类型,其余类型均允许。仅适用于完全信任的单一租户场景。
# 白名单示例:只允许Namespace和ClusterRole
clusterResourceWhitelist:
  - group: ""
    kind: Namespace
  - group: rbac.authorization.k8s.io
    kind: ClusterRole

# 黑名单示例:禁止创建ClusterRoleBinding和PersistentVolume
clusterResourceBlacklist:
  - group: rbac.authorization.k8s.io
    kind: ClusterRoleBinding
  - group: ""
    kind: PersistentVolume
对比维度 Whitelist(推荐) Blacklist(谨慎使用)
安全模型 默认拒绝,显式允许 默认允许,显式拒绝
适用场景 多租户、严格隔离、合规审计 单租户、内部工具、快速迭代
维护成本 需持续更新允许列表 需持续监控新增风险类型
误配置风险 较低(遗漏导致拒绝,而非越权) 较高(遗漏导致越权风险)
关键安全警告:允许ClusterRole和ClusterRoleBinding意味着项目可以创建具有集群管理员权限的绑定。如果必须允许,请结合roles字段中的RBAC规则进一步限制具体操作。永远不要在生产项目中同时允许ClusterRole和ClusterRoleBinding而不附加任何约束。

4.4 项目级RBAC配置综合示例

以下是一个生产级AppProject配置,展示了三个维度的协同使用:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a-platform
  namespace: argocd
spec:
  sourceRepos:
    - 'https://github.com/company/team-a-manifests.git'
    - 'https://github.com/company/shared-libraries.git'
  destinations:
    - serverURL: https://kubernetes.default.svc
      namespace: team-a-prod
    - serverURL: https://kubernetes.default.svc
      namespace: team-a-staging
  clusterResourceWhitelist:
    - group: ""
      kind: Namespace
    - group: rbac.authorization.k8s.io
      kind: ClusterRole
    - group: rbac.authorization.k8s.io
      kind: ClusterRoleBinding
  roles:
    - name: project-admin
      description: "Team A project administrators"
      policies:
        - p, proj:team-a-platform:project-admin, applications, *, team-a-platform/*, allow
        - p, proj:team-a-platform:project-admin, exec, *, team-a-platform/*, allow
    - name: project-reader
      description: "Team A read-only members"
      policies:
        - p, proj:team-a-platform:project-reader, applications, get, team-a-platform/*, allow
评审清单:
  1. 确认sourceRepos未包含通配符*,且所有仓库均属于受信任组织。
  2. 确认destinations中的命名空间已通过Kubernetes RBAC或Namespace准入控制器隔离。
  3. 确认clusterResourceWhitelist未包含CustomResourceDefinition(CRD)——允许CRD可能导致集群范围的安全漏洞。
  4. 确认roles中的策略遵循最小权限原则,未授予不必要的delete或sync权限。
项目级RBAC配置决策流程 AppProject 配置入口 sourceRepos 仓库来源 destinations 部署目标 集群资源准入控制 精确匹配 / 通配符 / 多仓库 serverURL + namespace 精确控制 Whitelist 推荐 / Blacklist 谨慎 策略组合评审与准入校验 Application 创建/同步 允许/拒绝 评审要点 三个维度必须同时满足才能通过准入校验;任一维度拒绝则整个Application被拒绝

4.5 常见误配置与规避策略

误配置场景 风险描述 规避策略
sourceRepos: ["*"] 允许所有Git仓库,包括恶意或未审计仓库 替换为https://github.com/your-org/*或精确URL列表
destinations中namespace: "*" 应用可部署到集群任意命名空间,打破多租户隔离 显式列出每个允许的命名空间
同时使用Whitelist和Blacklist 语义冲突,Argo CD行为不可预测 只选择一种模式,推荐Whitelist
允许CustomResourceDefinition在Whitelist中 项目可安装任意CRD,可能导致集群级安全漏洞 从Whitelist中移除CRD,使用Operator管理CRD
未配置roles策略 项目成员无法执行任何操作(即使仓库和目标已配置) 至少配置一个project-admin角色并绑定用户
自动化校验建议:在CI/CD流水线中加入argocd proj get <project-name> -o yaml命令,结合yq或kubectl diff对项目配置进行静态分析,确保每次变更都符合组织安全基线。