📚 课程目录第4章自动化轮换实践

4、自动化轮换实践：基于AWS KMS的自动轮换、Kubernetes Secrets轮换、CI/CD管道中的密钥轮换

说实话，手动轮换密钥这件事，我干过太多次了。早些年在一家金融科技公司，每个月要轮换几十个数据库密码，全靠运维同事写脚本、跑定时任务。每次轮换都像在走钢丝——生怕哪个服务没更新密钥，半夜被电话叫醒。

后来我悟出一个道理：轮换这件事，必须交给自动化。人去做重复操作，迟早会出错。机器不会累，不会忘，也不会把密钥贴到群里。

这一章，我就把我在AWS KMS、Kubernetes和CI/CD管道里做自动化轮换的经验，掰开揉碎了讲给你听。

4.1 AWS KMS自动轮换：云原生的“无感”方案

AWS KMS（Key Management Service）是我个人最常用的密钥管理服务之一。它原生支持自动轮换，而且配置起来非常简单。

但这里有个坑——KMS的自动轮换只生成新的加密材料，不会删除旧的。这意味着你之前加密的数据，用旧密钥材料依然能解密。说白了，KMS的轮换是“向前兼容”的。

核心机制：KMS自动轮换会创建一个新的密钥后端（Backing Key），但CMK（Customer Master Key）的ARN和ID不变。你不需要修改任何应用代码。

配置步骤其实就三步：

在KMS控制台创建一个对称CMK
在密钥详情页开启“自动轮换”
设置轮换周期（默认365天，可设为180天）

我记得有一次，客户问我：“我开启了自动轮换，为什么我的应用没有报错？”我告诉他，这就是KMS设计的初衷——让轮换对应用完全透明。你想想看，如果每次轮换都要改代码，那还叫什么自动化？

我的建议：对于合规要求高的场景（如PCI DSS），建议将轮换周期设为180天。虽然AWS默认是365天，但很多审计标准要求密钥有效期不超过1年。

不过，KMS自动轮换也有局限性。它只适用于对称密钥，非对称密钥需要手动轮换。另外，如果你用了KMS的多区域密钥，每个区域的轮换是独立的，需要分别配置。

4.2 Kubernetes Secrets轮换：从“重启Pod”到“热加载”

Kubernetes里的密钥轮换，是我踩坑最多的领域。早期我直接用kubectl delete secret再创建，结果Pod里的环境变量还是旧的——因为环境变量只在Pod启动时注入一次。

为什么会这样？因为Kubernetes Secrets挂载为环境变量后，不会自动更新。你改了Secret，Pod里的环境变量还是老样子。除非你重启Pod。

后来我改用Volume挂载的方式，情况就好多了。Secret以文件形式挂载到Pod里，Kubelet会定期同步（默认60秒），应用只要监听文件变化就能拿到新密钥。

我曾经踩过的坑：有一次我改了Secret，等了5分钟应用还没更新。排查了半天，发现是应用的配置文件里写死了文件路径，而挂载的Secret文件是符号链接。Kubernetes通过更新符号链接来实现原子更新，但有些应用不认符号链接。解决方案是让应用读取/etc/secret-volume/..data/目录下的文件。

下面是我常用的自动化轮换方案，用Reloader这个工具来实现：

# 安装Reloader
kubectl apply -f https://github.com/stakater/Reloader/releases/download/v1.0.0/reloader.yaml

# 在Deployment上添加注解，让Reloader自动重启Pod
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    secret.reloader.stakater.com/reload: "my-secret"
spec:
  template:
    spec:
      containers:
      - name: app
        image: myapp:latest
        volumeMounts:
        - name: secret-volume
          mountPath: /etc/secret-volume
          readOnly: true
      volumes:
      - name: secret-volume
        secret:
          secretName: my-secret

这样，每次我更新my-secret，Reloader就会自动滚动更新所有引用了这个Secret的Deployment。说白了，就是用自动化重启来换取密钥一致性。

但如果你不想重启Pod呢？那就得用热加载方案。比如用sidecar容器监听Secret变化，或者用Vault Agent注入动态密钥。

方案	优点	缺点	适用场景
环境变量 + 重启Pod	实现简单，兼容性好	需要重启，有短暂中断	非关键业务，可接受短暂中断
Volume挂载 + 文件监听	无需重启，实时更新	应用需支持文件监听	关键业务，要求零中断
Reloader自动重启	自动化程度高，无需改应用	滚动更新期间有资源消耗	大多数生产环境
Vault Agent注入	动态密钥，短生命周期	架构复杂，需额外组件	高安全要求，动态凭证场景

4.3 CI/CD管道中的密钥轮换：把轮换变成流水线的一环

CI/CD管道里的密钥轮换，是我觉得最有意思的部分。你想想看，代码每天都在变，密钥却几个月不换，这合理吗？

我个人习惯把密钥轮换做成一个独立的Pipeline Job，放在部署流程之前。这样每次部署新版本，都会先检查密钥是否需要轮换。

下面是一个GitLab CI的示例，用aws-cli和kubectl实现自动化轮换：

stages:
  - rotate-secrets
  - deploy

rotate-db-password:
  stage: rotate-secrets
  script:
    # 生成新密码
    - NEW_PASSWORD=$(openssl rand -base64 32)
    # 更新AWS Secrets Manager
    - aws secretsmanager put-secret-value --secret-id my-db-password --secret-string "$NEW_PASSWORD"
    # 更新RDS密码（需要提前配置好权限）
    - aws rds modify-db-instance --db-instance-identifier my-db --master-user-password "$NEW_PASSWORD"
    # 更新Kubernetes Secret
    - kubectl create secret generic db-password --from-literal=password="$NEW_PASSWORD" --dry-run=client -o yaml | kubectl apply -f -
  only:
    - main
  when: manual  # 手动触发，避免自动轮换导致意外

deploy-app:
  stage: deploy
  script:
    - kubectl apply -f deployment.yaml
  needs: ["rotate-db-password"]

这里有个关键点：轮换和部署必须串行执行。如果先部署再轮换，新Pod拿到的还是旧密钥，等轮换完又要重新部署。我早期犯过这个错，结果一个简单的发布搞了三次部署。

避坑指南：在CI/CD管道中轮换密钥时，一定要考虑回滚场景。我曾经遇到过轮换到一半管道失败，结果数据库密码改了，但应用没更新。后来我加了一个回滚步骤：如果部署失败，自动把密钥恢复到上一个版本。

对于使用GitOps的团队，我建议把密钥轮换和Git仓库同步。比如用Sealed Secrets或External Secrets Operator，让密钥的声明式管理成为GitOps的一部分。

嗯，这里要注意：不要把明文密钥提交到Git仓库。哪怕仓库是私有的，也不安全。我见过有人把数据库密码写在.env文件里提交，结果被CI日志泄露了。

4.4 三种场景的对比与选择

说了这么多，你可能想问：我到底该用哪种方案？

我的建议是：按场景选，不要一刀切。

如果你用AWS全家桶：优先用KMS自动轮换，省心省力。配合Secrets Manager，连应用代码都不用改。
如果你用Kubernetes：用Reloader + Volume挂载，兼顾自动化和零中断。如果对安全要求极高，上Vault。
如果你在CI/CD管道里：把轮换做成Pipeline的一个Stage，手动触发，串行执行。别忘了加回滚逻辑。

下面这张图，是我总结的自动化轮换决策流程：

最后说一句：自动化轮换不是一劳永逸的。你需要定期检查轮换是否正常执行，密钥是否真的被更新了。我建议每个月做一次轮换演练，模拟密钥过期场景，验证整个流程是否跑得通。

嗯，自动化轮换这件事，说白了就是用技术手段解决人的不可靠性。工具选对了，流程设计好了，剩下的就是让机器去干活。你只需要偶尔看看日志，喝杯咖啡就好。