📚 课程目录第3章常见Secret管理方案对比

常见Secret管理方案对比：Kubernetes Secrets、HashiCorp Vault、AWS Secrets Manager、Azure Key Vault

Secret管理方案选型，我个人认为这是平台工程里最容易被低估的一环。很多团队一开始都想着“先用K8s原生Secrets凑合着”，结果上了生产发现轮换、审计、跨集群同步全是坑。今天我把主流的四种方案拉出来，咱们一块看看各自的脾气秉性，免得以后踩雷。

Kubernetes Secrets——最原生的选择，但也是最裸的

Kubernetes Secrets本质上就是Base64编码的键值对，存在etcd里。你想想看，Base64又不是加密，谁都能解码。我在项目中遇到过不止一次，有人把数据库密码直接写在YAML里，然后提交到Git仓库……虽说Secrets可以配encryption at rest，但默认情况下etcd里的数据是明文的。

注意： K8s Secrets 只适合存放 非敏感 的配置（比如临时），或者作为其他Secret管理方案的中转层。千万别用它存生产环境的根密码。

它的好处是零依赖——你只要用K8s就自带。而且通过RBAC可以控制谁有权读某个Namespace下的Secret。但说到审计、动态轮换、细粒度访问控制……嗯，它基本没有。适合的场景是：小型实验环境、内部开发集群、或者作为Vault等方案的“临时缓存”。

HashiCorp Vault——老牌选手，功能最全

Vault是我个人最常用的方案。它提供动态Secret（比如给数据库生成一次性的临时账号）、自动轮换、加密即服务（Transit）、租约机制（Lease）。还有一大票后端——静态Secret、KV存储、PKI、SSH、数据库……基本上你能想到的安全场景它都能覆盖。

但是Vault的运维成本不低。它本身需要高可用部署（至少三台节点），后端存储要选etcd或Consul，还要配置解封（Unseal）流程。我记得有一次线上Vault节点重启后所有Secrets都不可读，因为忘了做Unseal——你们记住这个坑：生产环境一定要用自动解封（比如GCP KMS或AWS KMS做自动Unseal）。

经验分享： 如果你的团队有专门的SRE，并且Secret使用场景非常复杂（多集群、多云、动态凭证），Vault是不二之选。但要是只有两三个人搞平台，建议先掂量掂量运维成本。

AWS Secrets Manager——云原生选手，开箱即用

用AWS的朋友应该不陌生。Secrets Manager支持自动轮换（通过Lambda函数）、跨区域复制、细粒度IAM策略、审计集成CloudTrail。最爽的是它跟RDS、DocumentDB、Redshift这些服务深度集成，数据库密码可以一键自动轮换，不需要你写代码。

缺点呢？一是定价有点心疼——每个Secret每月0.4美元，加上轮换调用的Lambda费用，量大了成本上升很快。二是它没有Vault那种动态Secret生成能力，只能管理静态凭证。三是如果你用了多云，AWS Secrets Manager就管不了其他云上的Secret了。

  场景推荐： 纯AWS环境、不需要跨云、对自动轮换有刚需的团队。AWS Secrets Manager + IAM + CloudTrail 能搭出不错的审计闭环。

Azure Key Vault——微软生态里的安全保险柜

Azure Key Vault除了管理Secret，还能管证书和加密密钥。用它配合Azure Policy可以实现强制加密。逻辑上分两层：Vault（存放Secret和密钥）和Managed HSM（硬件安全模块，符合FIPS 140-2 Level 3）。权限通过Azure RBAC或访问策略控制。

Azure Key Vault的自动轮换比较“微软”——需要结合Azure Functions或Event Grid来实现，不像AWS那样开箱即用。另外它的配额限制比较多（比如每个Vault最多25个Secret? 实际上是软限制，但频繁调用会有节流）。我过去帮一个客户做迁移时，发现Azure Key Vault的REST API延迟比AWS要高一些，低频访问没问题，高频场景得心里有数。

一表看清差异

维度	K8s Secrets	HashiCorp Vault	AWS Secrets Manager	Azure Key Vault
存储加密	需手动启用etcd加密	默认AES-256 + Unseal机制	默认KMS加密	默认HSM/KMS加密
动态Secret	不支持	支持（数据库、SSH等）	不支持	不支持
自动轮换	无	需配置Agent或脚本	内置Lambda轮换	需Azure Functions
审计日志	需K8s审计日志	内置Audit Device	CloudTrail	Azure Monitor
跨云支持	仅K8s集群内	通用部署	仅AWS	仅Azure
运维复杂度	低	高	中	中
成本	免费（集群内）	社区版免费，企业版付费	按Secret/调用付费	按操作付费

  选型核心思路：你要的不是最安全的，而是跟你的平台规模和运维能力最匹配的。说白了——人少选云厂商的托管服务，人足够多且需要动态能力时上Vault。

一张图看懂四种方案的核心架构

下面这张SVG图是我按照实际部署经验画的。它把这四种方案在平台层的位置、访问控制、后端存储、以及和应用的交互方式做了对比。你看完应该能快速理解它们各自的长板短腿。

实际选型时我的一般建议

先回答两个问题：你们团队有几名SRE？Secrets的使用场景是静态凭证还是动态生成？

SRE少于2人，纯静态场景 → 直接上云厂商的托管方案（AWS SM 或 Azure KV）。
SRE充足，需要动态Secret、多云管控 → 上HashiCorp Vault，但要做好高可用和自动Unseal的设计。
只是K8s集群内部的临时用一下 → K8s Secrets + 手动加密etcd，别嫌麻烦。

我曾经踩过的坑： 有一个项目，团队为了图方便直接用K8s Secrets存储了生产数据库的超级管理员密码，而且没有开启etcd加密。后来某个开发人员把Secret导出到了日志文件，密码泄露了。当天晚上数据库被删了一半……从那以后我坚持：哪怕用云厂商的免费额度，也要上托管方案。

嗯，说到底，没有银弹。但记住一个原则：不要相信默认配置，不要跳过审计，不要忘记轮换。这三点做到，四种方案都能安全用起来。