📚 课程目录第2章 Argo CD项目(Project)基础

2. Argo CD 基础架构回顾：核心组件与工作流程

在深入多租户隔离与制品签名链路安全实践之前，必须重新梳理 Argo CD 的基础架构。Argo CD 并非一个单体应用，而是由三个核心微服务组件构成的协同系统：API Server、Repo Server 和 Application Controller。理解这三个组件的职责边界、通信方式以及数据流，是后续设计安全策略的基石。

2.1 核心组件职责与边界

下表从功能定位、安全敏感度、资源消耗三个维度对比了三个核心组件：

组件	核心职责	安全敏感点	关键资源
API Server	暴露 gRPC/REST 接口，处理用户认证、授权、RBAC、Webhook 触发	令牌管理、会话劫持、RBAC 配置错误	用户令牌、OIDC 配置、RBAC policy
Repo Server	克隆 Git 仓库、生成 Helm/Kustomize/Jsonnet 清单、缓存制品	Git 凭证泄露、恶意 manifest 注入、缓存投毒	SSH 私钥、Git 、仓库缓存
Application Controller	持续对比期望状态（manifest）与实时状态（K8s 集群），执行同步操作	集群凭证泄露、越权同步、资源滥用	集群 kubeconfig、同步权限

  安全视角提示： 在多租户场景下，Repo Server 是攻击面最集中的组件。它同时持有 Git 凭证和集群 manifest 生成逻辑，一旦被攻破，攻击者可以同时控制代码源和部署目标。

2.2 核心工作流程：从 Git 提交到集群同步

Argo CD 的完整工作流可以抽象为以下 6 个步骤。每一步都涉及组件间的 gRPC 或 REST 通信，且每一步都可能成为安全隔离的薄弱环节。

用户认证与请求：用户通过 CLI/UI/API 向 API Server 发起创建/同步 Application 的请求。API Server 验证 RBAC 权限后，将请求写入 Kubernetes CRD（Application 资源）。
Application Controller 轮询：Application Controller 监听 Kubernetes 集群中的 Application CRD 变化。当检测到新的 Application 或期望状态变更时，触发同步流程。
获取期望状态：Controller 向 Repo Server 发起 gRPC 调用，请求生成指定 Git 仓库、分支、路径下的 Kubernetes manifest 清单。
Repo Server 处理：Repo Server 使用配置的 Git 凭证克隆仓库，执行 Helm template / Kustomize build 等操作，生成最终的 manifest 并返回给 Controller。
状态对比与差异计算：Controller 将收到的期望 manifest 与目标集群中当前的实时资源状态进行对比，生成 Diff 结果。
执行同步：Controller 使用目标集群的 kubeconfig 凭证，通过 Kubernetes API 执行 Apply / Delete / Patch 操作，使集群状态趋近于期望状态。

2.3 组件间通信协议与安全通道

Argo CD 组件间的通信并非全部通过 Kubernetes API，而是采用了混合通信模型。理解这些通信链路对于配置网络策略和 TLS 加密至关重要。

API Server ↔ 用户：gRPC (HTTP/2) + REST (HTTPS)。默认使用自签名证书，生产环境应替换为受信任的 CA 证书。
API Server ↔ Application Controller：通过 Kubernetes API 监听 CRD 变化，属于集群内通信。
Application Controller ↔ Repo Server：gRPC TLS 加密通信。Controller 作为客户端，Repo Server 作为服务端。这是最关键的内部链路，必须启用 mTLS 以防止中间人攻击。
Repo Server ↔ Git 仓库：SSH (端口 22) 或 HTTPS (端口 443)。Repo Server 本地存储 Git 凭证，必须加密存储。
Application Controller ↔ 目标集群：HTTPS (Kubernetes API)。Controller 使用 kubeconfig 中的证书或令牌进行身份认证。

常见配置陷阱： 默认安装下，Application Controller 与 Repo Server 之间的 gRPC 通信可能未启用 TLS 证书验证。在多租户环境中，必须配置 --repo-server-strict-tls 标志，并确保 Repo Server 的 TLS 证书由内部 CA 签发。

2.4 关键配置示例：Repo Server 的 gRPC TLS 配置

以下是一个为 Repo Server 启用严格 TLS 的 Argo CD 配置片段。该配置确保 Application Controller 在连接 Repo Server 时验证服务器证书。

# argocd-cm ConfigMap 中的相关配置
data:
  # 启用 Repo Server 的 TLS
  repo.server.strict.tls: "true"

  # 指定 Repo Server 的 TLS 证书（Base64 编码）
  repo.server.tls.certificate: |
    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0t...
    LS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ==

  # 可选：指定 TLS 私钥（Base64 编码）
  repo.server.tls.privatekey: |
    LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQ==
    LS0tLS1FTkQgUlNBIFBSSVZBVEUgS0VZLS0tLS0=

最佳实践： 不要将私钥直接存储在 ConfigMap 中。应使用 Sealed Secrets 或 External Secrets Operator 将私钥注入到 Repo Server Pod 的挂载卷中，并设置文件权限为 0600。

2.5 架构总结：组件依赖关系图

下图展示了三个核心组件之间的依赖关系与数据流向。注意，Repo Server 是唯一同时与外部 Git 系统和内部 Controller 交互的组件，因此它成为安全隔离的关键枢纽。