第4章：主流KMS解决方案对比——AWS KMS、Azure Key Vault、GCP Cloud KMS、HashiCorp Vault

咱们CI/CD流水线里管密钥，工具选型确实是门学问。我个人这些年跟这几个主流方案都打过不少交道，有的适合云原生，有的擅长混合云，还有的能让你在本地也玩得转。说白了，没有完美的KMS，只有最匹配你环境的方案。

4.1 为什么需要对比？我踩过的大坑

我记得刚开始做DevSecOps时，觉得KMS都一样——不就是一个存密码的地方嘛。结果项目从AWS迁到Azure，才发现API签名方式完全不同，CI/CD里那一堆脚本全得重写。

我曾经在一个多云项目里，团队用了三个不同KMS，结果密钥轮换策略无法统一，差点导致生产事故。嗯，从那以后我养成了一个习惯：选KMS前，一定先画清楚“密钥从哪里来，到哪里去”。

你想想看，如果CI/CD流水线里每次构建都要去远端KMS取密钥，那延迟、成本、可用性都是问题。所以对比这些方案，不只是看功能列表，更要看它们怎么跟你的流水线“长在一起”。

4.2 四大KMS横向对照表

维度	AWS KMS	Azure Key Vault	GCP Cloud KMS	HashiCorp Vault
托管模式	全托管的云服务	全托管的云服务	全托管的云服务	自托管 / 云版 (HCP)
密钥类型	对称、非对称、HSM	对称、非对称、证书、HSM	对称、非对称、HSM	动态密钥、静态密钥、PKI、TOTP
CI/CD集成	AWS SDK / CLI, GitHub Actions	Azure CLI, GitHub Actions, DevOps Pipeline	gcloud CLI, Cloud Build	REST API / Agent / K8s集成
访问控制	IAM + Key Policy	RBAC (Azure AD)	IAM (GCP)	ACL / Policy / 多认证后端
高可用	区域复制、多区域	区域冗余 + 全局复制	区域 + 多区域	集群 + 自动解封
密钥轮换	自动轮换（每年/自定义）	自动轮换 + 手动更新	自动轮换（按周期）	手动 + 自动（配合调度）
定价模式	按API调用 + 密钥存储	按操作量 + 存储	按版本 + 操作	开源免费 / HCP按节点
适合场景	AWS原生生态	Azure / 微软生态	GCP原生生态	多云 / 混合云 / 本地

4.3 各方案深度拆解

AWS KMS —— 云原生密钥的“标准模板”

AWS KMS其实是最早把密钥管理做成通用服务的产品之一。我习惯叫它“密钥界的S3”——稳定、可靠、但需要你耐心读文档。

• 集成CI/CD：用AWS SDK在流水线里调用kms:Encrypt / kms:Decrypt。我通常在CodeBuild或GitHub Actions里先用IAM角色获取临时凭证，再解密环境变量。
• 避坑：请求量上去后，KMS会限速（默认每秒5000次）。我曾经有个部署脚本在循环里调KMS，直接被节流，弄得整个发布卡住。后来我加了本地缓存+批量处理。
• 个人推荐：如果你的CI/CD跑在AWS上，比如CodePipeline + CodeBuild，那KMS是无缝的。但别用它管多集群的K8s密钥——那事儿交给External Secrets Operator加KMS就够了。

# 在GitHub Actions里用AWS KMS解密的例子
- name: Decrypt secrets from KMS
  run: |
    aws kms decrypt \
      --ciphertext-blob fileb://encrypted.env.enc \
      --output text \
      --query Plaintext | base64 --decode > .env
  env:
    AWS_DEFAULT_REGION: us-east-1

Azure Key Vault —— 企业级“瑞士军刀”

Azure Key Vault给我的感觉是功能最全，但有时候也有点重。它能管密钥、证书、密码，甚至可以作为PKI后端。

• 集成CI/CD：Azure DevOps Pipeline有原生Key Vault Task。我更喜欢在GitHub Actions里用azure/keyvault-secrets action，那个会直接注入环境变量。
• 避坑：密钥名称大小写敏感！我踩过一个大坑：在Azure Portal里写了个“DB_Password”，但CI/CD脚本里写的是“db_password”，结果运行时报404。找了半小时才发现大小写不一致。
• 个人经验：Key Vault的防火墙（VNet集成）很强大，如果你有合规要求，可以把Key Vault完全锁在虚拟网络里，只让特定组件访问。

# Azure Key Vault在GitHub Actions中的配置
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
      - uses: azure/get-keyvault-secrets@v1
        with:
          keyvault: "MyKeyVault"
          secrets: "DB_CONNECTION"
      - run: echo "Connection: $DB_CONNECTION"

GCP Cloud KMS —— 极简主义者的选择

GCP Cloud KMS是我个人用得比较顺手的。它的API设计很简洁，跟GCP其他服务的集成度也高。

• 集成CI/CD：Cloud Build原生支持Secret Manager（不是直接Cloud KMS）。但如果你想用加密密钥，得在Cloud Build里调用gcloud kms decrypt。
• 避坑：Key版本管理要注意。GCP的Key版本是只读追加的，你用旧版本加密的数据，轮换后得用新版本重新加密。我有个旧系统就因为没注意这个，导致解密失败。
• 个人感受：Cloud KMS的权限模型很干净——只跟IAM打交道。但如果你需要动态密钥（比如临时数据库密码），那还是得用Secret Manager做缓存层。

HashiCorp Vault —— 多云游击战的王牌

Vault是我最喜欢的方案，没有之一。它不是云原生，而是“平台原生”——你可以在任何地方跑，包括K8s、虚拟机、甚至边缘设备。

• 集成CI/CD：Vault提供JWT/OIDC认证。我的做法是：在GitHub Actions里用JWT 登录Vault，然后获取暂时的数据库凭证或API 。
• 避坑：Vault的ACL策略写起来容易出错。我曾经写了一条策略，允许读取但忘了加list权限，结果CI/CD里能读具体的key路径，但没办法列出所有key，导致脚本循环失败。
• 个人经验：Vault的Dynamic Secrets是神器。你可以在CI/CD里直接申请一个临时RDS密码，用完即废。既安全又省心。

# Vault在GitHub Actions中用JWT认证的例子
make deploy:
  image: vault:latest
  script:
    - vault write auth/jwt/login \
        role=ci-role \
        jwt=${{ env.ID_ }}
    - DB_PASS=$(vault kv get -field=password kv/db/prod)
    - echo "DB_PASS=$DB_PASS" >> .env

4.4 知识结构图：KMS选型与CI/CD集成

下面这张图是我自己总结的。它帮你理清楚在不同场景下该选哪个KMS，以及它们跟CI/CD流水线的典型集成点。

4.5 我的选型建议

最后总结几条实战经验：

• 单一云场景：别犹豫，用云原生KMS。省去维护成本，还自带合规认证（SOC2、PCI DSS）。我自己在AWS项目里用KMS配合Secrets Manager，CI/CD跑得很流畅。
• 多云场景：Vault是唯一解。但要注意，Vault的运维门槛高。我记得有个团队因为Vault版本升级导致密钥策略不兼容，回滚了两次才搞定。建议从HCP Vault开始。
• 本地+云混合：Vault Agent是个好方案。你把Vault部署在本地，CI/CD通过Agent隧道访问，不需要开公网端口。我曾经帮一个金融客户这么搭过，审计报告直接满分。
• 动态密钥需求：只推荐Vault。云KMS大多只能管静态密钥，做不到“用完即废”。比如数据库临时密码，Vault的Dynamic Secrets几乎是标准答案。