CLOUD SECURITY LAB

🔐 Argo CD安全大师：RBAC配置与CI专用Scoped Token完整指南

—

by

cslab
in

大家好！在Kubernetes环境中运行GitOps时，我们必然会遇到一个难题。那就是关于“谁可以访问哪个项目，以及访问权限有多大？”的控制。

今天，我们将深入剖析Argo CD的权限控制引擎argocd-rbac-cm的结构，并详细了解被誉为安全巅峰的基于AppProject的CI专用令牌颁发方法。🛠️

1. 🏗️ Argo CD RBAC的核心：argocd-rbac-cm概述

Argo CD默认遵循基于角色的访问控制 (RBAC) 模型。负责此配置的ConfigMap正是argocd-rbac-cm。

📋 主要组成部分

  • Policy: 采用 p, , , , , 格式。
  • Scopes: 决定基于哪些组信息授予权限（例如：GitHub Org, Keycloak Group）。
  • Default Role: 授予未明确指定权限的用户的默认权限（通常建议使用 role:readonly 权限）。

    • 💻 argocd-rbac-cm基本配置示例

    YAML

    apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  # 1. 默认权限设置：未指定任何权限的用户只能读取 🧐
  policy.default: role:readonly

  # 2. 自定义策略定义 📜
  # 格式: p, <role/user/group>, <resource>, <action>, <object>, <allow/deny>
  policy.csv: |
    # 'dev-team'角色对'default'项目中的所有应用程序拥有'sync'和'get'权限
    p, role:dev-team, applications, get, default/*, allow
    p, role:dev-team, applications, sync, default/*, allow

    # 将特定组（OIDC集成时）映射到角色
    g, "my-github-org:eng-team", role:dev-team

  # 3. CSV数据源设置（默认）
  scopes: '[groups]'

    2. 🎯 特定项目的角色：AppProject Role

    不可能为所有用户授予整个集群的权限。Argo CD通过名为AppProject的单元提供逻辑隔离。

    🔍 AppProject Role的优势

    • 多租户: 强制A团队只管理A项目，B团队只管理B项目。
    • 精细控制: 可以设置在项目内部允许“创建应用程序”，但禁止“修改项目”。

    3. 🔑 CI管道的Scoped Token颁发方法

    这是最重要的问题：“Jenkins或GitHub Actions等CI工具如何安全地获取只能访问特定项目的令牌？” 💡

    使用全局管理员令牌（admin）非常危险。相反，您应该在AppProject内部创建一个Role，并颁发一个依赖于该Role的令牌。

    Step 1: 在AppProject内部定义角色

    首先，修改AppProject资源以创建用于CI的专用角色。

    YAML

    apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: ecommerce-project
  namespace: argocd
spec:
  description: "이커머스 서비스 전용 프로젝트"
  # ... 省略现有配置 ...
  roles:
    # 1. 定义一个名为'ci-bot'的角色。🤖
    - name: ci-bot
      description: "CI 파이프라인용 전용 토큰 역할"
      policies:
        # 此角色只能更新/同步此项目内部的应用程序
        - p, proj:ecommerce-project:ci-bot, applications, get, ecommerce-project/*, allow
        - p, proj:ecommerce-project:ci-bot, applications, sync, ecommerce-project/*, allow
        - p, proj:ecommerce-project:ci-bot, applications, update, ecommerce-project/*, allow

    Step 2: 使用Argo CD CLI颁发令牌

    创建角色后，现在需要生成一个与此角色关联的JWT令牌。通过Argo CD CLI执行此操作最为简便。

    Bash

    # 1. 请求为特定项目的角色创建令牌
# --expires-in: 设置令牌过期时间（例如：1年 = 8760h）
argocd proj role generate-token ecommerce-project ci-bot --expires-in 8760h

    ⚠️ 注意: 输出的令牌值只显示一次，因此务必将其存储在安全位置（例如：Vault、GitHub Secrets等）！

    Step 3: 在CI环境中使用令牌

    现在，将颁发的令牌注册为CI工具的环境变量（例如：ARGOCD_TOKEN），并按如下方式使用。

    Bash

    # 无需单独登录过程，仅凭令牌即可执行命令！🚀
argocd app sync my-app --server argocd.example.com --auth-token $ARGOCD_TOKEN

    4. 💡 运维提示：更安全的RBAC检查清单

    1. 最小权限原则 (Principle of Least Privilege): 绝不要将 policy.default 设置为 role:admin。将其设置为 role:readonly 或留空更为安全。
    2. 基于组的管理: 与其为单个用户分配 p 策略，不如通过 g 设置将 OIDC (Okta, Dex, GitHub) 组映射到角色。这将显著提高管理效率。
    3. AppProject 令牌管理: 定期更新（轮换）CI令牌，并使用 argocd proj role delete-token 命令立即废弃不再使用的令牌。

    📝 摘要表格

    类别 全局RBAC (argocd-rbac-cm) 项目RBAC (AppProject)
    管理范围 整个系统权限 (Admin, Readonly等) 特定项目内的资源权限
    主要对象 运维团队，全体开发人员组 特定服务开发团队，CI机器人
    令牌颁发 基于本地账户(Local User) 基于项目角色(Project Role)
    推荐用途 系统范围的访问控制 CI/CD管道集成 (Scoped)

    —

    💡 总结

    Argo CD 的安全性始于通过 argocd-rbac-cm 进行宏观控制与通过 AppProject 进行微观控制的和谐统一。特别是我们今天探讨的CI专用Scoped Token，是最大限度减少集群安全威胁同时提高自动化效率的最佳方法。

    立即将其应用到您的GitOps环境中吧！如果您有任何疑问，请在评论中留言。😊

    Comments

    发表回复

    您的邮箱地址不会被公开。 必填项已用 * 标注