进阶实战 · 上游 CA、四级信任链与无缝轮换
把 SPIRE 挂到一个稳定的上游 Root CA 之下,让所有 SVID 都链到一个永不变的根。下游验证方只认这一个根,SPIRE 内部 CA 随便轮换都不用重灌信任 —— 这也是**唯一能"无缝轮换"**的方案。
本文结论均来自一次真机闭环验证(SPIRE + 一个真实的下游 X.509 认证系统,以 CyberArk Conjur EE 为实测对象)。
四级信任链
- 给 SPIRE 的是中间 CA(不是根本身)作
UpstreamAuthority→ 根私钥永不进 SPIRE。 spire-server bundle show导出的信任 bundle 的根 = Root CA A(稳定)。- 下游验证方只需信任一个 Root CA A,SPIRE 内部怎么轮换都不用改下游。
为什么非上游不可:无缝轮换的关键(核心洞见)
实测结论:很多下游 X.509 验证系统要求呈现的信任材料里恰好一个根。
- 自签 SPIRE:CA 轮换会同时存在新旧两个自签根 → 塞进"只允许 1 个根"的下游会直接报错、认证悄悄坏掉。
- 上游 CA:根永远是同一个 Root CA A,轮换只是把**中间层(serverCA)**新旧并存一段重叠窗 → 无缝过渡。
所以 UpstreamAuthority 不是锦上添花,而是本类下游上唯一能"无缝轮换"的方案。这条经验在生产里价值极高 —— 见 高可用与大集群部署 的 CA 轮换机制。
两个信任域,不同设定(同一地基上对比)
| td-a(面向 EC2/VM) | td-b(面向 K8s) | |
|---|---|---|
| CA 密钥 | ec-p256 | rsa-2048 |
ca_ttl | 12h(短) | 48h |
| X.509 SVID TTL | 1h | 30m |
| JWT | 不启用(纯 X.509) | 启用(jwt_issuer + RSA) |
| 节点认证 | aws_iid + join_token | k8s_psat + join_token |
| 上游 | 中间 CA int-td-a → Root CA A | 中间 CA int-td-b → Root CA A |
两域互不联邦、各管各的 entry —— 起点平台就想在同一套地基上对比不同配置。要跨域互信再走 联邦。
无缝轮换运维剧本(真机验证,agent 全程免重引导)
bash
SOCK=/tmp/spire-server/private/api.sock
# 1) 让上游签一张新的 serverCA,先进 bundle(尚未启用)
spire-server localauthority x509 prepare -socketPath $SOCK
# 2) 把"根 + 中间 CA + 新 serverCA(+ 旧 serverCA)"刷新到下游的信任材料
# —— 下游需要:恰好 1 个根 + 全部中间层 + 当前 serverCA
# 3) 激活新 serverCA(新旧重叠,无断窗)
spire-server localauthority x509 activate -authorityID <prepared-id> -socketPath $SOCK- 下游的信任材料(如某认证系统的
ca-cert)= 恰好 1 个根 + 全部中间证书 + 当前 serverCA;缺任何一环都验不过链。 - 生产建议:把
ca_ttl拉长以降低刷新频率,或用 cron 定时刷新下游信任材料。
Tornjak · 图形化运营
命令行建 entry/selector 之外,可用 Tornjak(SPIFFE 官方管理 UI)图形化管理 entry、查看 agent 与 selector,降低运营门槛。适合把"谁能拿到哪个身份"交给运维/安全团队自助管理。