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
评审清单:
- 确认
sourceRepos未包含通配符*,且所有仓库均属于受信任组织。 - 确认
destinations中的命名空间已通过Kubernetes RBAC或Namespace准入控制器隔离。 - 确认
clusterResourceWhitelist未包含CustomResourceDefinition(CRD)——允许CRD可能导致集群范围的安全漏洞。 - 确认
roles中的策略遵循最小权限原则,未授予不必要的delete或sync权限。
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对项目配置进行静态分析,确保每次变更都符合组织安全基线。