HashiCorp Vault Secrets Operator (VSO) Kubernetes原生秘密管理指南

概述

在 Kubernetes 环境中规模化管理应用配置和凭证时，团队经常面临安全与敏捷之间的巨大张力。Kubernetes 原生 Secret 虽然提供了基础能力，但缺乏企业级治理所必需的全生命周期管理、策略执行和审计能力。随着环境扩展到多集群和混合云，管理问题从“如何将秘密注入 Pod”演变为“如何在整个生命周期（生成、注入、轮换、吊销）内安全、高效地管理秘密，同时不拖慢开发节奏”。HashiCorp Vault 作为广泛采用的企业级集中式秘密管理平台，需要一种与 Kubernetes 深度集成的标准模式来交付和自动化这一流程。Vault Secrets Operator (VSO) 正是为满足这一需求而设计的 Kubernetes 原生解决方案，它定义了现代化秘密交付的推荐标准。

核心概念

理解 Kubernetes 与 Vault 的集成模式，是做出正确架构决策的基础。以下是几种主要模式的核心概念解析。

Vault Secrets Operator (VSO)

VSO 是一个 OpenShift 认证的、专为 Vault 设计的 Kubernetes Operator。它通过自定义资源定义（CRDs）来声明式地管理 Vault 与 Kubernetes Secret 之间的同步关系。其核心思想是：应用无需“感知” Vault，只需像往常一样使用 Kubernetes Secret，而 VSO 负责在后台安全地从 Vault 获取秘密并维持其在 Kubernetes 中的状态，确保 Vault 作为唯一的、可信的权威数据源。

VSO Protected Secrets (VSO + CSI Companion)

这是 VSO 在高监管环境下的高级模式，需要 Vault Enterprise 版本支持。该模式下，VSO 不使用 Kubernetes Secret 对象来缓存秘密，而是结合一个 CSI 驱动，将秘密作为临时的内存卷（tmpfs）直接挂载到 Pod 中。秘密仅存在于 Pod 的生命周期内，永远不会被持久化存储到 etcd，从而满足最严格的数据驻留与合规要求。

Secrets Store CSI Driver (SSCSI)

SSCSI 是一个由社区维护的、供应商中立的驱动，允许将外部秘密存储提供者（如 Vault）中的秘密挂载为 Kubernetes 卷。它也可以实现将秘密绕过 etcd 存储。然而，当与 Vault 集成时，它缺乏 VSO/VSO Protected Secrets 所提供的深度生命周期管理功能，如自动漂移修复和全面的 Secrets Engine 集成。

Vault Agent Injector (Sidecar)

这是一个较早期的集成模式。它通过修改准入 Webhook，在 Pod 启动时注入一个 Vault Agent sidecar 容器。该 sidecar 负责认证、获取秘密并渲染到共享卷中。虽然功能强大，但其主要缺点是资源开销：每个 Pod 都需要运行一个专用的 Agent 容器，在大规模微服务架构下会导致显著的资源膨胀。

第三方 Secrets Operator

社区中存在许多通用的秘密同步 Operator。虽然它们可能适用于简单的场景，但在与 Vault 结合时，通常缺乏自动轮换、动态秘密、基于变更的滚动重启以及确保 Vault 作为唯一数据源的漂移修复等高级生命周期管理功能。组合使用多个工具来弥补这些缺失会导致运维复杂度的增加。

实践

在实际部署中，VSO 提供了两种主要的操作模式，通过声明式配置即可管理。

配置 VSO 同步 Vault 静态秘密

以下是 VSO 的一个基本 CRD 示例，它指导 VSO 将 Vault 中的数据库凭证同步到名为 app-db-creds 的 Kubernetes Secret 中：

apiVersion: secrets.hashicorp.com/v1beta1
kind: VaultStaticSecret
metadata:
  name: app-db-creds
  namespace: my-app
spec:
  vaultAuthRef: vault-auth
  mount: kv
  type: kv-v2
  path: apps/my-app/database
  refreshAfter: 30s
  destination:
    create: true
    name: app-db-creds

此配置实现了关键自动化：VSO 会以 refreshAfter 指定的时间间隔轮询 Vault 的 apps/my-app/database 路径，并将最新值同步到同命名空间下的 app-db-creds Kubernetes Secret。应用无需任何修改即可通过标准 Kubernetes 机制（环境变量或卷挂载）消费该 Secret。

选择操作模式

标准 VSO 模式：适用于大多数工作负载。秘密以 Kubernetes Secret 对象形式存在和同步，便于开发者使用。VSO 负责自动更新和漂移修复。
VSO Protected Secrets 模式：适用于强监管环境（如金融、医疗）。配置时需额外关联 CSI 伴侣驱动，秘密将被挂载为临时卷，确保其不写入 etcd。

两种模式下，VSO 均可配置监听 Vault 的变更事件，实现近乎实时的更新，并可自动触发应用程序的滚动重启以应用新凭证，完成端到端的自动化轮换。

SRE 要点

VSO 不仅仅是一个工具集成，它深刻影响了 Kubernetes 平台上秘密管理的可靠性工程实践。

与可靠性、可观测性、事件响应的关联

可靠性：VSO 通过自动化整个凭证生命周期（轮换、注入、漂移修复），消除了因秘密过期、手动操作失误或配置漂移导致的应用程序中断。其声明式模型与 Kubernetes 控制器模式一致，确保期望状态与实际状态持续收敛，是实现高可靠性的基石。
可观测性：VSO 作为集群内的 Operator，其同步状态、错误和性能指标可以被集群监控系统（如 Prometheus）采集。这为秘密同步的健康状况提供了关键的可观测性数据，帮助 SRE 团队快速发现问题。
事件响应：当需要紧急轮换某个泄露的秘密时，SRE 可以在 Vault 侧更新，VSO 会自动检测到变化并同步，必要时触发应用重启。这个过程是可控、可审计且高度自动化的，极大缩短了事件响应时间（MTTR）。

最佳实践与常见反模式

最佳实践：
- 标准化：在团队内推广将 VSO 作为与 Vault 集成的默认标准，避免集成模式的分散化。
- 最小权限：为 VSO 使用的 Vault 身份配置精细的策略，仅允许其读取/更新特定路径的秘密。
- 监控同步状态：将 VSO 的 VaultStaticSecret 或 VaultDynamicSecret 资源状态纳入集群健康度检查。
- 区分模式：为绝大多数应用使用标准 VSO；仅对必须避免 etcd 存储的极高敏感性工作负载启用 VSO Protected Secrets。
常见反模式：
- 在 CI/CD 中硬编码或明文传递秘密：这破坏了零信任基础，应使用 VSO 从 Vault 动态获取。
- 滥用 Secret 对象存储长期凭证：应利用 Vault 的动态秘密引擎（如数据库、AWS）为每个 Pod 生成短期、唯一的凭证。
- 忽视漂移修复：手动修改被 VSO 管理的 Secret，会导致其被自动覆盖回 Vault 版本，可能引发困惑。应理解并利用 VSO 的“单一数据源”特性。