📚 课程目录第3章 SPIRE架构与核心组件

3. SPIRE架构与核心组件

SPIRE 并不是一个单体程序，而是一组职责清晰、通过标准接口协作的组件集合。理解 SPIRE 的关键，不是记住每个组件的名字，而是弄清“谁负责证明节点身份、谁负责证明工作负载身份、谁负责签发和保存密钥、谁负责把身份交到进程手里”。本节围绕这七个核心组件展开，先讲清各自职责，再串起一次完整的身份签发流程。

一、Server 与 Agent：控制面与数据面的分工

SPIRE Server 是整个信任域的根控制面。它持有 CA 私钥（或通过 Upstream Authority 委托签发），负责注册条目（Registration Entry）管理、签发 SVID、维护信任包（Trust Bundle），并对外暴露 Node API 与 Registration API。Server 通常部署在受控的服务器环境，不直接接触业务工作负载。

SPIRE Agent 运行在每一个需要签发身份的工作节点上，是数据面。它通过 Node API 向 Server 证明“我是这个节点”，拿到节点级 SVID 后，再在本地为工作负载签发 SVID。Agent 暴露 Workload API（Unix Domain Socket），工作负载通过它获取身份，无需接触 Server，也无需持有长期凭证。

两者的关系可以概括为：Server 决定“谁被允许拥有什么身份”，Agent 决定“本节点上哪个进程实际拿到这个身份”。策略在 Server，执行在 Agent。

二、两类证明者：Node Attestor 与 Workload Attestor

Node Attestor 解决“节点身份从哪来”。它利用底层平台的可信属性证明节点，例如 AWS IID（实例身份文档）、Kubernetes PSAT（Projected Service Account Token）、Azure MSI、GCP IIT，或 X.509 证书。Server 侧配置的 Node Attestor 与 Agent 侧配置的插件必须匹配，否则节点无法完成证明。

Workload Attestor 解决“进程身份从哪来”。Agent 通过它检查进程的内核或运行时属性，例如 Unix UID/GID、Docker 容器标签、Kubernetes Pod 的 ServiceAccount 与 namespace、systemd 单元名。这些属性被拼成选择器（Selector），例如 unix:uid:1001 或 k8s:ns:payments，再与 Server 上的注册条目匹配。

两者的本质区别是：Node Attestor 面向“机器/节点”，由 Server 验证；Workload Attestor 面向“进程/容器”，由 Agent 验证。前者建立节点信任，后者建立工作负载信任。

三、Upstream Authority、KeyManager 与 DataStore

Upstream Authority 是可选的“上游 CA 连接器”。当企业已有 PKI（如 Vault、AWS ACM PCA、自建中间 CA）时，SPIRE Server 不自己当根，而是让上游 CA 签发 Server 的中间 CA 证书。这样 SPIRE 签发的 SVID 能直接融入现有信任链，便于与既有系统互信。

KeyManager 负责 CA 私钥的生成、存储与签名操作。默认 disk 插件把私钥以明文文件放在 Server 数据目录，仅适合实验；生产环境应使用 aws_kms、gcp_kms、azure_key_vault 或 vault 等插件，让私钥永不离开 HSM/KMS，签名通过远程调用完成。

DataStore 是 Server 的持久化后端，保存注册条目、节点证明记录、SVID 映射与信任包。默认 sqlite3 适合单节点实验；生产环境推荐 postgres 或 mysql，以支持多 Server 高可用与并发写入。

四、一次完整的 SVID 签发流程

下面这张图把七个组件放在同一条链路上，展示从节点启动到工作负载拿到 SVID 的完整交互。图中区分了“节点证明阶段”和“工作负载证明阶段”，并标出各组件在流程中的位置。

流程可以拆成五个关键动作：Agent 启动后调用 Server 的 Node API，携带平台证明材料；Server 的 Node Attestor 验证通过后，用 KeyManager 签名、经 DataStore 记录，签发节点 SVID；Agent 拿到节点 SVID 后建立本地信任；工作负载通过 UDS 调用 Workload API；Agent 用 Workload Attestor 采集进程选择器，与 Server 下发的注册条目匹配，匹配成功则本地签发工作负载 SVID 并缓存、按 TTL 轮换。

五、配置示例与观察点

下面是一段 Server 配置片段，展示 Node Attestor、KeyManager、DataStore 与 Upstream Authority 的典型组合。示例参数属于教学假设，实际值需按环境替换。

server {
  trust_domain = "example.org"
  bind_address = "0.0.0.0"
  bind_port    = "8081"
  data_dir     = "/opt/spire/data/server"
}

plugins {
  NodeAttestor "aws_iid" {
    plugin_data { }
  }
  KeyManager "aws_kms" {
    plugin_data {
      region     = "cn-north-1"
      key_policy = "spire-server"
    }
  }
  DataStore "postgres" {
    plugin_data {
      connection_string = "postgres://spire:pass@db:5432/spire?sslmode=verify-full"
    }
  }
  UpstreamAuthority "vault" {
    plugin_data {
      vault_addr = "https://vault.example.org:8200"
      pki_mount  = "pki_int"
      role       = "spire-server"
    }
  }
}

观察点有三个：一是 Server 启动日志中是否出现 KeyManager 与 DataStore 初始化成功；二是 Agent 日志中是否出现 Node attestation successful 与节点 SVID 的 SPIFFE ID；三是工作负载侧调用 Workload API 后，返回的 SVID 中 spiffe://example.org/... 路径是否与注册条目一致。若第三步失败，优先用 spire-server entry show 核对选择器，而不是反复重启 Agent。

记忆口诀：Server 管策略与根密钥，Agent 管本地执行；Node Attestor 证明“机器是谁”，Workload Attestor 证明“进程是谁”；Upstream Authority 决定信任链起点，KeyManager 决定私钥在哪，DataStore 决定状态存哪。

把这七个组件放回一次签发流程中，就能理解 SPIRE 的设计意图：把长期密钥风险集中到 Server 与 KMS，把高频、贴近业务的签发下沉到 Agent，用两类 Attestor 分别建立节点与工作负载的信任，最终让每个进程都拿到短生命周期、可自动轮换的 SVID。