SPIRE 实战 · 三节点真实部署
这个板块不复述规范,而是真正把 SPIRE 跑起来,用一套三节点部署回答两个最要命的问题:SVID 到底"长什么样"由什么决定?一个具体进程"能不能拿到、拿到哪张"又由什么决定?
所有证书、令牌、命令输出都来自这套真实环境(作者 homelab LAN)。
拓扑:一个 Server,两种平台的 Agent
- spire-server / spire-agent 是 ESXi 上克隆的一次性 VM;K3S agent 落在现有 rancher 集群(v1.31),只新增
spire/demo两个命名空间。 - SPIRE 版本 1.15.1(官方最新 release;源码解读分析的 1.15.2 概念一致)。
本板块四篇
| 篇目 | 讲什么 | 一句话收获 |
|---|---|---|
| 什么是 SVID(形式 vs 实际) | 用两张真实签出的 SVID,讲清"形式的决定因素"(规范+类型+三层配置)与"实际的决定因素"(attestation+匹配+授权) | 主体不能自证身份——换个 uid / ServiceAccount,身份立刻从"有"变"无" |
| 三层配置逐项实验 | 每个配置项(ca_ttl/-selector/unix:sha256/-dns/jwt_issuer…)到底影响 SVID 的什么,配真实 A/B 与负向输出 | ca_ttl 封顶一切;selector 是准入不是形状;连"你是不是那段二进制"都由内核实测 |
| 三节点部署与复现 | 从零把这套环境搭起来的配置、脚本与命令(server.conf、agent.conf、K3S DaemonSet…) | 拿去改改 IP/域名就能在你自己的环境复现 |
| 进阶 · 上游 CA 与无缝轮换 | 把 SPIRE 挂到稳定 Root CA 下,四级信任链、无缝轮换、两域对比、Tornjak(真机验证) | UpstreamAuthority 是"无缝轮换"的唯一方案——根恒定,只换中间层 |
三个"啊哈"时刻(先剧透)
- 同一台 server、同一个信任域,两个 agent 的身份结构却完全不同——
spire/agent/join_token/<uuid>vsspire/agent/k8s_psat/rancher-k3s/<node-uid>,因为认证方法不同。 - 同一份配置、同一个 agent,把进程 uid 从 1001 换成 1002,
fetch x509就从"拿到/vm/web"变成"什么都拿不到"。 - 配了很大的
-x509SVIDTTL(48h)却没生效?因为被ca_ttl死死封顶——排查 TTL 问题的头号原因。
想先看代码怎么实现的?见 SVID 颁发全流程 与 整体架构。