📚 课程目录第4章常见密钥管理服务

4. 常见密钥管理服务：四把钥匙怎么选？

密钥轮换这件事，说到底你总得有个地方存密钥。扔代码里？肯定不行。放环境变量里？也不靠谱。所以得用专门的密钥管理服务。市面上主流的就这四家：AWS、Azure、GCP 的云原生服务，加上 HashiCorp Vault。我跟它们都打过不少交道，今天聊聊各自的脾气。

4.1 AWS Secrets Manager

AWS 家的，跟 Lambda、ECS 这些服务集成得特别紧。我觉得它是“开箱即用”做得最好的一个。你建一个 Secret，直接就能配自动轮换策略，甚至帮你调用 Lambda 函数去执行轮换脚本。

核心能力： 自动轮换 + 跨账户访问 + 细粒度 IAM 权限。

举个我在项目中用过的例子：一个微服务启动时需要读取 RDS 密码。用 AWS Secrets Manager，服务在初始化时调用 get_secret_value 接口，拿到最新版本。轮换周期设成 30 天，Lambda 自动生成新密码并更新 RDS。

# 我用 Python 写的取值片段
import boto3
from botocore.exceptions import ClientError

def get_secret(secret_name, region):
    client = boto3.client('secretsmanager', region_name=region)
    try:
        response = client.get_secret_value(SecretId=secret_name)
        return response['SecretString']
    except ClientError as e:
        # 我曾经掉进过权限不足的坑
        print(f"获取失败，检查 IAM 策略: {e}")
        return None

注意：AWS Secrets Manager 按 Secret 数量 + API 调用次数收费。如果你的轮换频率很高，比如每小时一次，账单会涨得很快。我有个客户曾经一个月花了 300 多美元，就是因为每个 Secret 每天读了几万次。

4.2 Azure Key Vault

微软家的，跟 Azure Active Directory 深度绑定。如果你整个技术栈都是 Azure 生态，那用它最省心。Key Vault 支持两种层级：Standard 和 Premium，Premium 还能做 HSM 硬件加密。

它有个很实用的功能叫“软删除”，删掉的密钥会保留一段时间，防止手滑。我记得有次我误删了一个生产环境的密钥，幸好软删除开着，几分钟就恢复回来了，吓出一身冷汗。

我的习惯： 给每个应用建独立的 Key Vault，用 RBAC 控制访问。别把所有密钥塞进一个 Vault，不然审计日志会乱成一团。

轮换靠什么呢？Azure Key Vault 本身没有“自动轮换”按钮，但你可以结合 Azure Functions 或者 Logic Apps 来写轮换逻辑。官方建议的方式是——每次轮换时创建新版本，旧版本保留以便回滚。

# 我用 Azure CLI 手动轮换一个密钥
az keyvault secret set \
  --vault-name "my-vault" \
  --name "db-password" \
  --value "新密码" \
  --expires "2025-12-31T23:59:59Z"

其实说白了，Azure 的灵活度比 AWS 差一点，但如果你用的是 .NET 或 C# 环境，集成的 SDK 体验非常好。

4.3 GCP Secret Manager

Google 的，起步晚但设计得很干净。它跟 GCP 的 IAM 和 Cloud KMS 配合，可以做到密钥加密密钥（KMS 加密 Secret）。你想想看，如果连密钥管理服务本身的存储都是加密的，那安全性又高了一层。

我去年做过一个项目，用 GCP Secret Manager 管理。它有个我很喜欢的功能叫“Secret 版本控制”——每次更新都会保留历史版本，你可以随时回退到上一版。轮换触发可以用 Cloud Scheduler 定时调用 Cloud Function 去写新值。

  特色： 付费很简单——每个 Secret 版本每月 0.06 美元，访问次数另算。对于小团队来说，成本非常可控。

# 我用 gcloud 命令创建 secret
gcloud secrets create my- \
  --replication-policy="automatic" \
  --data-file="key.txt"

# 轮换时直接添加版本
gcloud secrets versions add my- \
  --data-file="new-key.txt"

要注意的是，GCP Secret Manager 没有内置的自动轮换调度器，你得自己搭。不过 Cloud Scheduler 加 Cloud Functions 也花不了多少时间。

4.4 HashiCorp Vault

这货跟前面三个不太一样——它是跨云的，可以跑在任何地方。你可以在本地机房、AWS EC2、Kubernetes 集群里部署它。Vault 的轮换能力是最强的，几乎所有支持的引擎（如数据库、AWS、PKI）都自带动态 Secret 功能。

什么叫动态 Secret？就是你每次获取密码，Vault 临时生成一个有效期为几小时的新密码，用完就过期。你想想看，这还需要轮换吗？根本不需要！用一次换一次。

曾经踩过的坑： 我刚开始用 Vault 时，把存储后端配成了文件系统，结果集群重启后数据丢了。Vault 必须用高可用的存储后端，比如 Consul、Raft 或者 S3。别省这个钱。

# 我用 Vault 生成 PostgreSQL 动态凭据
vault read postgres/creds/my-role

# 输出示例
Key             Value
---             -----
lease_id        postgres/creds/my-role/xxxx
password        A1b2C3d4...  # 临时密码
username        v--my-role-xxxx

Vault 的缺点也很明显——它需要你部署和维护。如果你团队规模不大，运维成本可能比用云原生的服务高。

4.5 选型对比表

维度	AWS Secrets Manager	Azure Key Vault	GCP Secret Manager	HashiCorp Vault
自动轮换	内置 + Lambda	需自建 Function	需自建 Scheduler	动态 Secret 自动变
跨云可用	仅 AWS	仅 Azure	仅 GCP	任意环境
运维复杂度	低（托管）	低（托管）	低（托管）	高（自建）
版本回退	支持	支持	支持	支持
单价（举例）	0.4 美元/Secret/月	0.03 美元/10k 操作	0.06 美元/版本/月	开源免费，但需自管

4.6 四家服务的选型逻辑图

下面这张图是我自己总结的。选哪种，主要看你部署环境和团队运维能力。

4.7 集成 CI/CD 时的通用考虑

不管你用哪个服务，CI/CD 集成时都要注意几个共性问题：

认证方式： 流水线里怎么证明自己是合法的？AWS 用 IAM Role for EC2/CodeBuild，Azure 用 Managed Identity，GCP 用 Workload Identity Federation，Vault 用 AppRole 或 Kubernetes Auth。千万别把 Access Key 写死在代码里。
权限最小化： 只给流水线读取特定密钥的权限，不要给管理权限。我见过有人给 CI 角色配了 Secrets Manager 完整权限，结果同事在流水线里误删了所有 Secret…….
失败处理： 密钥轮换期间，如果新密钥还没生效，旧密钥被删了怎么办？建议保留并行版本，新旧同时生效一段时间（比如 5 分钟窗口）。

我的一个小技巧： 在 CI 步骤里，先验证密钥是否可读、是否过期，再往下走。如果轮换操作失败，整个 Pipeline 应该暂停而不是直接退出。把错误信息打印到构建日志，方便排查。

4.8 小结

这四种服务各有千秋。AWS Secrets Manager 适合 AWS 深度用户，省心；Azure Key Vault 跟 Active Directory 绑定，安全且合规；GCP Secret Manager 清爽且便宜；HashiCorp Vault 是“万能钥匙”，但需要你有运维能力。选哪个，看你的团队和场景。