Vault 与 Kubernetes 动态密钥及自动轮换实战

把密码从配置文件移到 Kubernetes Secret，只是改变了保存位置，并没有解决长期凭据、多人共享、无法追责和轮换困难。更成熟的方案是让工作负载先证明自己的身份，再按策略领取短期凭据，并在到期后自动失效。

本文以 HashiCorp Vault 与 Kubernetes 为例，讲解认证、策略、动态数据库账号、证书、注入方式、轮换、审计、灾备和紧急访问。

一、先划清职责

Kubernetes ServiceAccount
  → Kubernetes Auth / JWT Auth
      → Vault Token（短期）
          → 动态数据库账号 / 云凭据 / 证书 / KV Secret

各层职责：

层 负责内容
Kubernetes 工作负载身份、命名空间、ServiceAccount
Vault Auth 验证身份并映射到 Vault Role
Vault Policy 限制可访问路径和能力
Secrets Engine 生成、保存或签发凭据
Lease 控制有效期、续租和吊销
Audit Device 记录认证与密钥访问行为

二、威胁模型

部署前先回答：

  • Pod 被入侵后能读取哪些密钥；
  • ServiceAccount Token 泄漏后可使用多久；
  • 某个命名空间能否冒充另一个命名空间；
  • Vault Root Token 如何保管；
  • Unseal 或恢复密钥由谁持有；
  • 审计日志能否被业务管理员篡改；
  • Vault 不可用时业务如何降级；
  • 密钥轮换失败是否会导致全局中断。

安全设计不是“部署一个 Vault”就结束。

三、生产架构

建议：

  • Vault 使用高可用存储；
  • 多实例跨节点或故障域部署；
  • 全链路 TLS；
  • 使用自动解封或受控的人工解封流程；
  • 审计日志输出到受保护系统；
  • 管理面和业务访问面隔离；
  • 备份、快照和恢复演练；
  • 管理员使用企业身份源登录；
  • Root Token 仅用于初始化和极端恢复。

Vault 服务端、存储后端和自动解封密钥不能位于同一故障域。

四、Kubernetes认证

1. 创建专用ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-api
  namespace: production

不要让所有应用共用 default ServiceAccount。

2. 配置Vault认证

Vault Kubernetes Auth 会验证 ServiceAccount Token，并依据命名空间、ServiceAccount 和 Audience 映射角色。

角色应限制：

  • bound_service_account_names；
  • bound_service_account_namespaces；
  • audience；
  • token policies；
  • token TTL 与最大 TTL。

避免使用 * 让任意命名空间和 ServiceAccount 领取相同权限。

3. 使用短期投射Token

现代 Kubernetes 应使用 TokenRequest/Projected Service Account Token，明确 audience 和有效期，不依赖长期自动生成 Token。

五、最小权限Policy

示例：

path "database/creds/payment-readonly" {
  capabilities = ["read"]
}

path "kv/data/production/payment/config" {
  capabilities = ["read"]
}

策略原则：

  • 按应用和环境分开；
  • 读写分开；
  • 静态KV和动态凭据分开；
  • 禁止业务应用访问 sys/* 和认证管理路径；
  • 不按个人姓名给生产服务绑定永久策略；
  • 对高风险路径增加控制组或人工审批。

六、动态数据库账号

动态账号由 Vault 在请求时创建，到期后自动删除或吊销。

流程：

应用认证 → 读取 database/creds/role
        → Vault创建临时数据库用户
        → 返回用户名、密码和lease
        → 应用使用
        → 到期续租或吊销

角色需要定义 creation statements、default TTL、max TTL 和 revocation statements。

数据库管理员应限制 Vault 管理账号的权限，使其只能创建符合命名规则和权限边界的临时用户。

七、应用如何获得密钥

方式一：应用直接调用Vault

优点：

  • 能处理续租和动态凭据；
  • 不在磁盘生成文件；
  • 行为最明确。

缺点：

  • 应用需要集成 SDK；
  • 必须正确处理 Token、Lease、续租和故障。

方式二：Vault Agent Injector

通过 Sidecar 或 Init Container 把密钥渲染到共享内存卷中的文件。

适合不方便改造的应用，但要处理：

  • 文件权限；
  • 模板；
  • 更新后的应用重载；
  • Sidecar 资源；
  • Pod 终止时清理。

方式三：Secrets Store CSI Driver

将外部密钥挂载为卷。适合文件消费方式，但应用是否能实时读取新内容仍需验证。

方式四：External Secrets

把外部密钥同步为 Kubernetes Secret，兼容性好，但密钥会重新进入 etcd。需要启用 etcd 加密、RBAC 和 Secret 生命周期治理。

八、选择注入方式

场景 建议
新应用且需要动态凭据 应用直接调用或Agent
老应用读取配置文件 Agent模板
证书/密钥文件挂载 CSI Driver
必须使用原生Secret External Secrets并强化etcd安全
高频轮换数据库账号 应用直接处理lease

不要为了统一而强迫所有应用使用同一种方式。

九、密钥轮换

轮换需要同时设计“签发新值”和“让消费者切换”。

标准过程：

  1. 创建或签发新凭据；
  2. 保持旧凭据短暂有效；
  3. 更新应用；
  4. 验证新连接；
  5. 观察错误率；
  6. 吊销旧凭据；
  7. 验证旧凭据失效；
  8. 记录审计证据。

如果应用只在启动时读取一次文件，Vault 即使更新文件也不会自动让应用使用新值。需要支持热加载、连接池刷新或滚动发布。

十、租约与续租

应用必须理解：

  • lease_duration；
  • 是否 renewable；
  • 续租失败如何处理；
  • 最大 TTL；
  • 凭据吊销后现有连接是否立即失效；
  • Vault 短暂不可用时是否继续使用尚未过期凭据。

不要在每个请求中重新领取数据库账号，这会给 Vault 和数据库带来不必要压力。

十一、PKI与证书自动化

Vault PKI 可签发短期证书。建议设置：

  • Root CA 离线或高等级保护；
  • Intermediate CA 在线签发；
  • 角色限制域名、TTL 和用途；
  • 客户端自动续期；
  • 吊销列表和 OCSP 策略；
  • 私钥只在工作负载边界生成或传递；
  • 证书轮换告警。

短期证书减少对吊销的依赖，但仍需要时钟同步和续期能力。

十二、KV静态密钥治理

并不是所有密钥都能动态生成。对 KV 中的静态密钥：

  • 使用版本化引擎；
  • 设置访问策略；
  • 避免在一个对象中混放多个系统密钥；
  • 记录负责人、来源、用途和轮换周期；
  • 建立过期扫描；
  • 不在日志、工单和聊天中复制明文；
  • 对删除操作保留恢复窗口；
  • 定期验证业务已切换到新版本。

十三、审计

Vault 审计日志用于回答：

  • 谁在什么时间认证；
  • 使用了哪个角色和策略；
  • 访问了哪个路径；
  • 请求是否成功；
  • 从哪个来源发起；
  • 是否发生批量读取和异常失败。

审计日志通常会哈希敏感值，但仍应视为敏感数据。至少启用两个审计设备以降低单个审计目标故障导致服务受阻的风险，并将日志发送到防篡改平台。

十四、监控与告警

至少监控：

  • Vault sealed 状态；
  • leader 与 HA 状态；
  • 请求速率和延迟；
  • 5xx 与权限拒绝；
  • 活跃 Token 和 Lease；
  • 租约创建、续租、吊销失败；
  • 存储延迟与容量；
  • 审计设备错误；
  • 证书和 Token 临期；
  • 自动解封失败；
  • 数据库动态用户清理失败。

十五、备份与恢复

Integrated Storage 场景应使用官方快照机制，并把快照复制到独立位置。

恢复演练要验证：

  1. 新 Vault 集群可恢复；
  2. HA 和解封正常；
  3. Auth、Policy、Secrets Engine 存在；
  4. 审计设备重新启用；
  5. 业务可以重新认证；
  6. 动态凭据能够创建和吊销；
  7. 旧 Token 和 Lease 的行为符合预期。

备份文件、解封材料和自动解封密钥必须分别保护。

十六、Vault不可用时怎么办

按业务分级：

  • 已获得且未过期的凭据是否可继续使用；
  • 应用是否缓存 Token；
  • 新 Pod 是否必须等待 Vault；
  • 是否允许读取短期本地缓存；
  • 哪些业务宁可停止也不能降级到长期凭据；
  • 恢复后如何避免集中续租和启动风暴。

不要设置一个永久万能密码作为所有系统的“兜底”。紧急方案也必须最小权限、限时、审批和审计。

十七、Break-glass紧急访问

紧急访问流程应包括：

  • 触发条件；
  • 两人审批；
  • 身份强认证；
  • 临时高权限；
  • 极短 TTL；
  • 全程审计；
  • 操作录像或命令记录；
  • 事后立即吊销；
  • 复盘和常规权限修复。

紧急账号要定期演练，不能等事故发生时才发现无法登录。

十八、常见故障

permission denied

依次检查认证角色绑定、ServiceAccount、命名空间、audience、Policy路径和 capability。不要直接给 sudo 策略验证。

token reviewer失败

检查 Vault 与 Kubernetes API 连通性、Reviewer JWT、CA、TokenReview权限和目标集群。

Agent文件已更新但应用仍用旧密码

应用可能只在启动时读取文件，或连接池仍复用旧连接。增加热加载、信号处理或滚动发布。

动态数据库用户未删除

检查 revocation statement、数据库连接、Vault日志和数据库锁。必要时执行有审计的人工清理，并修复角色定义。

Vault重启后业务集中失败

检查 sealed 状态、存储、leader、自动解封和服务发现。应用要有指数退避，避免形成认证风暴。

十九、生产落地路线

  1. 从低风险只读密钥开始；
  2. 接入企业身份和审计；
  3. 建立 HA、监控和备份；
  4. 为单个应用启用 Kubernetes Auth；
  5. 上线动态只读数据库账号；
  6. 演练轮换和Vault不可用；
  7. 扩展到证书和云凭据；
  8. 治理历史静态Secret；
  9. 建立统一策略模板；
  10. 定期回收闲置角色和路径。

二十、生产检查清单

身份与权限

  • [ ] 每个应用使用独立ServiceAccount；
  • [ ] Vault Role限制命名空间、ServiceAccount和audience；
  • [ ] Policy按应用、环境和读写分离；
  • [ ] Token与Lease均为短期并有最大TTL。

运行

  • [ ] Vault跨故障域高可用；
  • [ ] TLS、审计、监控和告警完整；
  • [ ] 自动解封与恢复流程已演练；
  • [ ] 应用能处理续租、轮换和短暂不可用。

数据安全

  • [ ] Root Token和恢复材料受控；
  • [ ] 静态密钥有负责人和轮换周期；
  • [ ] Kubernetes etcd中密钥已加密；
  • [ ] 日志和工单不出现明文；
  • [ ] Break-glass限时、审批、审计并定期演练。

参考资料

Copyright © yan-jian.com 2023 - 2026 · Powered by GitBook更新时间： 2026-10-25 22:26:28

results matching ""

    No results matching ""