第3章：常见云厂商 Secrets 服务介绍
做多云Secrets统一接管，你首先得知道各家的“原配”长什么样。说白了，就是AWS、Azure、GCP、阿里云它们各自自带的那个“保险柜”。
我见过不少团队，一上来就想搭一个统一的平台，结果连自家云上有啥能力都没摸清。最后搞出来的方案，要么重复造轮子，要么跟云原生生态脱节。今天这章，我们就把主流云厂商的Secrets服务拉出来遛遛。
我个人习惯先看产品的核心定位，再看它能跟什么服务“原生配合”。你想想看，一个Secrets服务如果跟你用的计算服务都集成了，你干嘛还要自己去写SDK？
3.1 AWS Secrets Manager
AWS家的Secrets Manager，是我接触最早的云原生秘钥服务。当时我还觉得，这不就是存个密码嘛，能玩出什么花来？结果用上之后才发现，它跟RDS的自动轮换机制是真的省心。
核心能力：
- 自动轮换：内置对RDS、Redshift、DocumentDB的轮换模板。我曾经帮一个客户把数据库密码轮换周期从人工30天改成自动7天，运维压力直接减半。
- 细粒度权限：通过IAM Policy，你可以精确控制谁可以读哪个Secret的哪个版本。
- 跨账户共享：使用Resource-based Policy，可以跨AWS账号授权。
但这里有个坑——计费。AWS Secrets Manager是按API调用次数收费的。我记得有个团队把Secret读到内存后，每次请求都去调用SDK取一次，一个月下来账单吓人。
3.2 Azure Key Vault
Azure Key Vault（简称AKV）给我的第一印象是——它不仅仅是一个Secrets服务，更像是一个“钥匙总管”。它把密钥、证书、机密分成了三类独立的资源类型。
几个值得说的点：
- 硬件安全模块（HSM）：AKV提供了两种SKU——Standard（软件加密）和Premium（HSM-backed）。如果业务有合规要求，比如PCI-DSS，那HSM基本上没得选。
- 托管HSM：这是Azure的一个“隐藏大招”。它让你拥有一个独享的HSM池，密钥连Azure自己都看不到。我参与过一个金融项目，合规要求密钥必须“离云”管理，托管HSM就是唯一选项。
- 与Azure生态的集成：AKV天然跟Azure AD、AKS（Kubernetes）、VM Extension、App Service打通。你甚至在ARM模板里就能引用Key Vault里的值。
说实话，Azure Key Vault的权限模型稍微复杂一些。它有访问策略（Access Policy）和Azure RBAC两套体系。我个人习惯统一用RBAC，这样跟其他Azure资源的管理方式一致。
3.3 GCP Secret Manager
GCP的Secret Manager是三者中最“简单”的——API设计得很干净，概念少，学习曲线低。但这不代表它能力弱。
| 特性 | 说明 | 我的经验 |
|---|---|---|
| 版本管理 | 每个Secret有多个版本，可以启用/禁用/销毁特定版本 | 回滚操作非常快，直接enable旧版本即可 |
| IAM条件绑定 | 可以基于资源标签、时间、IP等条件控制访问 | 配合VPC Service Controls，能实现零信任网络 |
| 审计日志 | 所有读写操作写入Cloud Audit Logs | 有一次排查泄漏事件，全靠日志追踪到具体服务账号 |
| 复制策略 | 支持多区域复制，提升可用性 | 注意跨区域复制会产生额外网络费用 |
GCP Secret Manager有一个我很喜欢的设计：它不强制轮换。你需要自己通过Cloud Scheduler + Cloud Functions实现自动化轮换。这给了你更多灵活性，但也意味着你要自己负责轮换逻辑的健壮性。
3.4 阿里云 KMS & 凭据管家
阿里云的KMS（Key Management Service）核心是密钥管理，而凭据管家是它上面一层专门管Secrets的服务。这个设计跟GCP有点类似，但更强调“凭据”的概念。
凭据管家的主要能力：
- 支持数据库密码、、SSH密钥等常见的Secret类型。
- 自动轮转：目前支持RDS MySQL、Redis等常用数据库。
- 与RAM权限集成：通过RAM Policy控制谁可以访问哪个凭据。
说实话，阿里云的这套体系在国内云厂商里算是比较成熟的。我在一个国内电商项目里用过，它的KMS跟容器服务ACK（Kubernetes）做了csi-secrets-store-driver的集成，部署起来很顺畅。
但有一点需要注意：区域隔离。阿里云的KMS和凭据管家是区域级别的服务，不能跨Region直接访问。如果你的业务部署在多区域，需要在每个Region都创建一份凭据，然后通过同步工具或统一控制面来管理。
3.5 核心差异对比
上面讲完了各家的情况，你可能更关心它们到底有什么核心差异。下面这个表是我根据自己的经验整理的，供你参考。
| 对比维度 | AWS Secrets Manager | Azure Key Vault | GCP Secret Manager | 阿里云 KMS+凭据管家 |
|---|---|---|---|---|
| API风格 | JSON + HTTPS | REST + Graph | gRPC/REST | REST + SDK |
| 内置轮换 | 强（RDS原生） | 中（需Function触发） | 弱（需自行实现） | 中（RDS部分支持） |
| HSM支持 | CloudHSM集成 | 原生托管HSM | Cloud HSM集成 | KMS支持HSM |
| 权限模型 | IAM + Resource Policy | Access Policy + RBAC | IAM + Conditions | RAM + KMS Policy |
| 多区域复制 | 手动或借助备份 | 不支持原生复制 | 支持多区域副本 | 不支持原生复制 |
| 计费模式 | API次数 + 存储 | 操作次数 + HSM费用 | API次数 + 存储 | 操作次数 + 密钥数量 |
你看，每家都有自己的“杀手锏”。AWS轮换做得最好，Azure HSM最硬核，GCP API最简洁，阿里云在国内生态集成最全。统一接管要考虑的，就是如何在保持各自优势的前提下，构建一个公共的管理面。