方案对比 · 我已经有 X,还需要 SPIFFE 吗?

一句话:SPIFFE 不是"又一个 CA",而是给工作负载一套自动签发、免硬编码密钥、可跨云验证的身份。下面把它和你可能已经在用的方案逐条摊开对比 —— 有些场景它们够用,有些场景才该上 SPIFFE。

核心分歧:静态长期凭据 vs 动态短时身份

传统方案:身份=你声称持有的那张长期证书/密钥,泄露即长期有效、轮换靠人工。 SPIFFE:身份=平台能证明的事实(在哪台机器、是什么进程),SVID 短命、自动轮换、私钥永不出机。

维度	手工 mTLS(自签+分发)	传统 PKI / 企业 CA	HashiCorp Vault	SPIFFE / SPIRE
身份是什么	证书 CN / IP	证书 CN / SAN	令牌 / 证书	SPIFFE ID(`spiffe://…`)
谁能拿到证书	谁拿到密钥谁就是	申请者(人工审批)	有 token / 认证通过者	平台 attestation 证明后才发(主体不能自证)
签发方式	手工 / 脚本	手工 / 半自动	API 自动	自动 · 按需批量
有效期	常年(懒得轮换)	数月~数年	可短可长	默认 1h,自动轮换
密钥分发	手工拷贝 / 塞进镜像	手工 / 配置管理	应用拉取	本地生成,私钥永不出机
防伪造(attestation)	❌ 无	❌ 无	部分(auth 方法)	✅ 节点+工作负载双重认证
轮换	手工、易忘、易过期	手工、痛	需应用配合	✅ 自动、临期前轮换
撤销	难(CRL/OCSP 少用)	CRL / OCSP	有	✅ 短 TTL + taint/revoke
多云 / 异构统一	❌ 各管各	一般	一般	✅ 一套身份跨 AWS/GCP/Azure/K8s
跨域 / 跨组织	❌	手工交叉签	❌	✅ 联邦(交换 bundle)
免密访问云服务	❌	❌	需集成	✅ JWT-SVID + OIDC
开放标准 / 生态	无	X.509 标准	私有为主	✅ CNCF 开放标准,Istio/Envoy 原生
运维成本 / 门槛	低(小规模)→ 高(规模化崩)	中	中	中高(有学习曲线,但规模化后省心)

手工 mTLS —— 几个服务、内网、基本不变:够用。一旦服务数上量、频繁扩缩容、跨环境,密钥分发与轮换会失控 → 该上 SPIFFE。
传统 PKI / 企业 CA —— 给人 / 设备 / 少量长期服务发证:成熟好用。但它是"长周期、手工、按 CN/IP 信任",不解决海量工作负载的自动短周期身份与 attestation → 可让 SPIRE 挂在你的企业 CA 之下(UpstreamAuthority),既复用既有信任根,又获得自动化。
HashiCorp Vault —— 机密管理(DB 口令、API Key)、PKI 引擎:很强,建议保留。但它不原生做"工作负载 attestation";常见做法是二者协同(见下)。
该上 SPIFFE/SPIRE —— 动态、异构、跨云、大规模、要零信任与可审计:这正是 SPIFFE 的主场。

SPIFFE 很少要你推倒重来,更多是补齐"工作负载身份"这一层,和你现有的东西咬合:

Vault 作上游 CA:SPIRE 的中间 CA 由 Vault PKI 签,信任链上溯 Vault;工作负载再用 SVID 免密登录 Vault 取机密 —— 消灭"取 secret 还得先有个 secret"的鸡生蛋。
企业 PKI 作上游:SPIRE 挂在既有根 CA 下,签出的 SVID 能被现有 PKI 体系验证。
服务网格:Istio / Envoy 本身就用 SPIFFE ID —— 你上网格,某种程度已经在用 SPIFFE。