Infisical 替代品：团队密钥管理工具怎么选

🇺🇸
Read in English: Infisical Alternatives: How to Choose a Secrets Manager for Your Team

设想这样一个周三下午三点，一个入职两周的后端在群里问：生产的数据库连接串是多少？

有人开始翻聊天记录。翻了四十多屏，找到一个半年前实习生发的 .env 文件。文件里三个 key，两个早就换过了，剩下那个还是去年测试环境的。真正在跑的那一份，在运维同学的笔记本里，文件名是 env_backup_final(2).txt。

事情最后是解决了，但解决得很不体面。更麻烦的是后面那半句：那个实习生三个月前就离职了，走的时候没人想起来，他手机里还存着一份完整的生产配置。

这种事很少是因为谁不小心。它更像是流程里少了一个零件。密钥从来没有一个”唯一正确的存放位置”，于是它只能散在聊天记录、笔记软件、CI 的变量框和某个人的家目录里。一旦散开，轮换就变成了考古：你得先找到所有副本，才谈得上换掉。

一个文件格式撑了太久

.env 这种东西本来没有错。十多年前它流行起来，是因为它简单到不需要解释：一行一个键值，本地跑得动，部署时丢给进程就行。

问题在于它默认了一件事：这个文件是安全的，而且只有你一个人有。

团队一变大，这两个前提就同时失效。文件要发给新同事，要放进 CI，要让测试环境的机器读到，于是它开始复制。副本一多，就没有”当前版本”这个概念了。你改的那份可能不是线上跑的那份，你删掉的那个 key 可能还有三个服务在用。

Infisical 就是冲着这件事做的。它在 GitHub 上开源（https://github.com/Infisical/infisical），官网是 infisical.com，把自己定位成一个管理 secrets、证书、访问权限的平台，最近这两年也把手伸向了 AI Agent 的凭据管理。核心思路很朴素：密钥不再以文件形式流转，而是集中存放，客户端按身份去取，取的过程留痕。

对很多团队来说，这套东西已经够了。但”够用”和”合适”是两件事，所以还是会有人来问替代品。

为什么会想换掉它

几种很具体的情况。

一是自托管的成本。Infisical 可以自己部署，这对数据不出内网的团队是刚需。但它毕竟是一套完整的服务，后面站着数据库、缓存、后端进程，还要考虑升级、备份、TLS。一个五个人的团队，本来只是想让密钥别再在群里飞，结果每个月要花半天维护一个平台，这笔账不一定划算。

二是账单的形状。云端版本按席位和功能分层，人一多就往上跳一档。有些团队其实只有三五个服务需要管密钥，却要为整个研发部门付费。

三是已有的技术栈。如果你们所有东西都跑在 AWS 上，IAM 已经在管身份了，再引入一套独立的权限体系，意味着每次有人入职离职，要在两个地方改权限。多一个系统，就多一个忘记同步的地方。

四是需求本来就窄。有人要的只是”把这些配置加密了提交进 Git”，不需要 UI，不需要服务器，也不需要谁来看仪表盘。

这四种情况指向的答案完全不同。所以在看具体工具之前，值得先把问题分个类。

保险柜、钥匙串和信封

市面上的工具大致落在三个位置上，理解这个分层比记功能列表有用得多。

第一类是集中式的密钥服务。它有服务器、有数据库、有 API，客户端拿着身份去换密钥。Infisical、HashiCorp Vault、Doppler、AWS Secrets Manager 都在这一层。它们解决的是”唯一可信来源”的问题，附带访问控制和审计。

第二类是密码管理器伸出来的手。1Password 和 Bitwarden 本来是给人存密码的，后来加了一套给机器用的接口。它们解决的是”团队已经在用了，顺手”的问题。

第三类根本不算服务，是文件加密工具。SOPS 是代表，它把配置文件里的值加密，结构留明文，加密结果可以直接进 Git。它解决的是”我不想再养一台机器”的问题。

这三类工具的能力边界差别很大，混在一起比功能表会得出很奇怪的结论。真正该问的是：你需要的是一个能回答”谁在什么时候读了生产密码”的系统，还是一个能让配置文件安全地待在仓库里的办法。

HashiCorp Vault 和 OpenBao：能力上限，也是运维下限

设想一家做支付的公司，十几个后端，三套环境，合规那边要求能出一份报告，写明谁在什么时候读过生产数据库密码。这种场景下 Vault 几乎是默认答案。

它是这类工具里做得最久的一个，最厉害的地方是动态凭据。数据库密码不是存着发给你，而是每次临时生成一个，带上有效期，用完自动失效。应用被入侵、日志泄露了凭据，能用的窗口只有几分钟。这一点是静态密钥方案做不到的，也是 Vault 至今难以被完全替代的原因。

代价在运维。Vault 装完不能直接用，它自己要一套存储（内置的 Raft 或者外部数据库），要初始化，要 unseal，要考虑高可用和备份。很多小团队第一次部署，会卡在 TLS 证书和 unseal key 怎么保管这两件事上。而 unseal key 保管本身就是个哲学问题：你为了安全把它拆成几份分给几个人，然后发现其中两个人同时休假了。

许可证这块有一道分水岭。2023 年 HashiCorp 把 Vault 从 MPL 2.0 改成了 BSL 1.1，社区随后分叉出 OpenBao，现在由 Linux Foundation 托管，继续用 MPL 2.0。所以如果你们的顾虑是”开源能不能长久”，OpenBao 是那条路；如果要厂商支持和托管服务，原版 Vault 的企业版和云产品还在。

一句话概括：如果你们有明确的合规要求、有人懂运维、需要动态凭据，Vault 或 OpenBao 值得那份额外的复杂度。如果这三条缺一条，它大概率会变成一个”部署了但没人敢动”的系统。

Doppler：把密钥管理做成一个网页

Doppler 走的是完全相反的路。注册，建项目，建环境，把 .env 的内容粘进去，本地装个 CLI，然后 doppler run -- npm start，环境变量就注入进进程了。整个过程十分钟，不需要读文档。

它基本是纯 SaaS，没有主打的自托管版本。对”密钥绝不出内网”的团队，这一条就直接出局。但对一个十来个人、服务跑在 Vercel 和 Fly.io 上的团队，它省下的正是最贵的东西：没人需要为密钥再维护一台机器。

定价按席位和项目分档，有免费档可以试。集成是它的强项，GitHub Actions、GitLab、Kubernetes 都有现成做法，CI 里取密钥基本是照抄文档。

它的界面语言很直白：环境叫 dev、staging、prod，密钥可以按环境覆盖，改完立刻生效，不用重启服务（如果你的代码是启动时读环境变量，那还是得重启，这点它没法替你解决）。

它的边界也很清楚：存的是静态密钥，没有动态凭据，权限模型是按项目和环境分的，够用但谈不上精细。团队到了需要”这个人只能读 prod 的三个 key”的程度，会开始觉得别扭。

AWS Secrets Manager：如果你们本来就住在 AWS 里

对全栈都在 AWS 上的团队，这个选项最大的吸引力不是功能，而是不用再引入一个新的信任边界。

IAM 已经在管人和服务的身份了，Secrets Manager 直接复用这套：哪个 Lambda 能读哪个密钥，就是一条 IAM policy。轮换也能配，RDS 的凭据可以设成定期自动轮换，由 Lambda 去改密码。审计走 CloudTrail，虽然日志不好读，但至少是同一套体系。

短板在 AWS 之外。多云、本地机房，或者开发同学在自己 Mac 上跑服务，都要额外绕一圈。跨账号共享密钥也有，但配置起来不算愉快。

计费按密钥数量和 API 调用次数算。密钥多、调用频繁的团队要留意，比如每个 Pod 启动都拉一次配置，累计下来会比直觉中的贵。很多人会用缓存层或者参数存储来挡一部分请求，这也是这类按调用计费服务的常见做法。

它适合的场景很明确：单一云、身份已经在 IAM 里、不打算为密钥管理单独买一个产品。反过来，如果你们有一半服务在阿里云或者自建机房，这个方案会迅速变得别扭。

1Password 和 Bitwarden：从密码管理器长出来的

这两个的逻辑很好理解。团队本来就在用 1Password 存账号密码，那让机器也来读同一套东西，好像顺理成章。

1Password 的 Secrets Automation 给的是服务账号和 CLI，CI 里用 op 命令取密钥，另外有一层可以自托管的连接服务，用来把请求转进内网。Bitwarden 的 Secrets Manager 是独立产品，按机器账号和席位计价，价格通常比同类低一些，对偏好开源的团队也友好。

它们的优势是使用惯性。人已经在用了，上手成本近乎零，界面是给人看的，不是给审计员看的日志流。对新同事来说，”去 1Password 里找”这句话不需要培训。

限制在模型上。这类工具的核心是”存着的密钥”，没有动态凭据，也没有细到单个 key 的策略引擎。等到团队几十人、需要区分谁能读生产、谁只能读测试、谁能读但看不到值的时候，会发现选项只有那么几个。它们是很好的起点，但不一定是终点。

SOPS：不要服务器，把密文塞进 Git

SOPS 是另一个物种。它不是一个服务，是一个命令行工具，作用是把 YAML、JSON、ENV 文件里的值加密，键的结构保持明文，于是加密后的文件可以直接提交进仓库，diff 还能看。

加密用的密钥可以是云上的 KMS（AWS、GCP、Azure），也可以是 age 或者 PGP。谁能解密，取决于谁有那把 KMS key 的权限。文件里会记录用了哪个 key，所以换 key 的时候不用改文件本身。

好处是零基础设施。没有服务器，没有可用性，没有备份，也没有”平台挂了所有人都没法部署”这种事故。它由 Mozilla 发起，MPL 2.0 许可，社区一直在维护。

坏处也是同一个东西。没有界面，没有访问日志，没有”谁在什么时候读了什么”的记录。轮换意味着把所有文件重新加密、重新提交、重新走一遍评审。人一多，靠 KMS 权限来控制谁能解密，粒度会显得太粗。

它最适合的场景是配置本身就是代码、团队习惯用 Git 评审一切、并且已经有 GitOps 流程。比如集群的 manifest、Terraform 的变量文件。放在这种地方，SOPS 几乎是完美的。要它兼任访问控制和审计，那就是用错了工具。

把四个维度摆在一起

功能列表容易骗人，因为每个工具都会说自己支持环境隔离、支持 CI 集成、支持审计。真正决定选型的是四件更硬的事：钱怎么付、东西放在哪、代码归谁、以及它能不能接进你现有的流程。

所以下面这张表只比这四项。定价我尽量只写模式不写数字，因为各家调价频繁，写死了反而是误导。

工具	定价模式	部署方式	授权协议	集成方式
Infisical	开源自用免费，云端按席位与功能分档	云端或自托管	核心开源，企业功能单独授权	CLI、各语言 SDK、Kubernetes Operator
HashiCorp Vault	开源版免费，企业版按节点与席位报价	以自托管为主，另有托管服务	Vault 为 BSL 1.1，OpenBao 为 MPL 2.0	HTTP API 驱动，认证与存储后端可插拔
Doppler	按席位与项目分档，有免费档	SaaS 为主	闭源	CLI、SDK、主流 CI 与平台集成
AWS Secrets Manager	按密钥数量与 API 调用计费	AWS 托管	闭源	IAM、Lambda 轮换、AWS SDK
1Password Secrets Automation	随团队订阅打包	SaaS 加可自托管的连接服务	闭源	CLI、服务账号、CI 集成
Bitwarden Secrets Manager	按机器账号与席位计费，有免费档	SaaS，也可自托管	核心开源，部分功能单独授权	CLI、SDK、CI 集成
SOPS	免费	无服务，本地命令行	MPL 2.0	KMS、age、PGP，配合 Git 工作流

表格里没有”安全性”这一列，是因为到了这个层级，加密算法都不是短板，短板在用法。一个配错了权限的 Vault，比一个用对的 SOPS 危险得多。

怎么选：按团队现在的样子

看了这么多，真正做决定的时候，问自己四个问题就够了。

密钥需不需要离开你的内网。如果监管或者客户合同写了不能出，那么 SaaS 全部排除，剩下 Infisical 自托管、Vault/OpenBao、Bitwarden 自托管、SOPS。

有没有人愿意为这件事值班。密钥管理系统的故障是会阻塞部署的。如果没有一个人能说”这东西我负责”，选一个不用你管的托管服务，比选一个功能最强的自托管系统更负责任。

要不要动态凭据。要，就只剩 Vault 和 OpenBao 这条线，其它都是静态存储。不要，就别为它付复杂度。

你更愿意付钱还是付时间。SaaS 按月付费，账单清楚；自托管省钱，但省下的是现金，花掉的是人。小团队往往低估后者。

还有一个容易被忽略的点：迁移成本。密钥管理系统的迁移不是换个 API 地址那么简单，你要把所有服务的取值方式改一遍，把 CI 的配置改一遍，还要在最紧张的那几天保证不出错。所以这件事最好一次做对，或者干脆别做。半途而废留下两套系统并存，是最糟的状态。

回到那个周三下午

如果把开头那个场景当作一个假想团队，他们的处理方式其实很小：把 .env 从聊天记录里搬到一个统一的地方，给每个环境一个地址，给每个人一个账号，而不是一份文件。离职流程里加一行：撤销密钥访问。

具体用哪个工具，反而是次要的。重要的是从那天起，”生产配置在哪”这个问题有了唯一答案。

工具选型这件事经常被写成一张功能对照表，但真正让人睡不着的，从来不是少一个功能，而是某个深夜你突然想起来，半年前离职的那个人的手机里，可能还存着一份能连上生产库的文本文件。

选哪个工具，取决于你想在多长时间内不再想起这件事。

延伸阅读

查看完整选型指南 →

Stay updated with our latest AI insights

2026 年录屏工具怎么选：Loom 替代方案实测，这 5 个真的能打