6.3 密钥隐身术：Sealed-Secrets 与 Vault 的 K8s 密钥管理之道

1. 引言：Base64 ≠ 加密

K8s Secret 天然“弱保护”：默认以 Base64 存储于 Etcd，未开启 at-rest 加密时属于明文。密钥管理的目标是：密钥不落盘、最小暴露、可审计、可轮换。

2. Sealed Secrets：把密钥“安全地放进 Git”

2.1 工作原理

• 控制器（集群内）持私钥；
• 开发者用公钥加密密文，生成 SealedSecret；
• 控制器在集群内解封为标准 Secret。

2.2 示例

apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: db-cred
  namespace: order
spec:
  encryptedData:
    password: AgA...

• 加密在本地进行，Git 中仅存密文；
• 私钥仅存在集群中（注意备份与轮换）。

2.3 优缺点

• 优：GitOps 友好、无密钥下发；
• 缺：密钥生命周期管理较弱（轮换/审计/动态颁发能力有限）。

3. Vault：企业级密钥与动态凭证

3.1 能力

• 统一密钥保管与审计；
• 动态数据库凭证（短期租约，自动回收）；
• KMS/Transit 加密服务；
• 租约/续约/吊销全生命周期。

3.2 Vault Agent Injector（K8s 注入）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  template:
    metadata:
      annotations:
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "app-role"
        vault.hashicorp.com/agent-inject-secret-db: "database/creds/readonly"
    spec:
      serviceAccountName: app-sa
      containers:
      - name: app
        image: app:latest

• Vault 通过 SA/JWT 验证 Pod 身份，自动把密文注入为文件/环境变量；
• 凭证到期后自动续约/轮换。

4. Etcd 加密与最小权限

• 开启 at-rest 加密：API Server EncryptionConfiguration；
• Secret 最小权限：RBAC 限制 get/list/watch；
• 节点与 Pod 安全：禁用 hostPath/root，限制 Secret 挂载可见性。

5. 选型建议

• 中小团队 + GitOps 为主：Sealed Secrets/SOPS；
• 金融/合规/多团队共享：Vault（集中化、动态凭证、审计）。

6. 总结

密钥不是配置。选择合适的工具链与治理模式，让密钥“看得见、拿不走、到点失效、查得到”。