K8s Secrets管理方案介绍（K8s密钥管理方案）etcd、Sealed Secrets（kubeseal、ArgoCD）、ESO、HashiCorp Vault、CSI

文章目录0. 前言1. Kubernetes 原生 Secret2. etcd Encryption3. Sealed Secrets基本介绍为什么需要 Sealed Secrets完整工作流程详解1. 本地加密阶段开发者操作2. Git 存储阶段3. 部署阶段GitOps 工具4. 解密阶段集群内部为什么这种设计是安全的安全边界划分权限控制与传统方法的对比传统方式不安全Sealed Secrets 方式多集群管理问题问题场景解决方案实际使用示例开发者日常流程为什么适合 GitOps总结4. External Secrets Operator (ESO)5. HashiCorp Vault6. Vault Agent Injector7. Secrets Store CSI Driver8. 云厂商托管方案演进路线当前主流推荐个人项目 / 小团队中大型企业高安全要求0. 前言在 Kubernetes 发展过程中Secrets 一直是一个争议点Kubernetes 原生 Secret 并不是真正意义上的“安全存储”Base64 不是加密只是编码Secret 会出现在 etcd、节点内存、Pod 环境变量等多个位置企业环境通常不会直接使用原生 Secret因此围绕 Secret 管理逐渐形成了几种主流方案。1. Kubernetes 原生 Secret最基础的方案。apiVersion:v1kind:Secretmetadata:name:db-secrettype:Opaquedata:password:cGFzc3dvcmQPod 中引用env:-name:DB_PASSWORDvalueFrom:secretKeyRef:name:db-secretkey:password优点Kubernetes 内置配置简单无额外组件缺点Base64 不是加密Secret 默认存储于 etcdetcd 是一个分布式、高可用的键值Key-Value存储系统在 Kubernetes 中etcd 是整个集群的核心数据存储被称为 Kubernetes 的大脑或注册表运维人员容易获取GitOps 不方便管理适合开发环境测试环境小型项目2. etcd EncryptionKubernetes 官方提供的静态加密方案。开启后Secret ↓ API Server ↓ 加密 etcd配置 EncryptionConfigurationapiVersion:apiserver.config.k8s.io/v1kind:EncryptionConfigurationresources:-resources:-secretsproviders:-aescbc:keys:-name:key1secret:base64-key优点官方支持部署简单防止直接读取 etcd缺点Key 仍需自行管理API Server 解密后依然明文无法解决 Git 泄漏问题适合所有生产环境基本可以视为最低安全要求。3. Sealed Secrets基本介绍由 Bitnami 提出。核心思想Secret ↓ kubeseal ↓ SealedSecret ↓ Git开发者kubesealsecret.yamlsealed-secret.yaml生成apiVersion:bitnami.com/v1alpha1kind:SealedSecret提交 GitGit ↓ ArgoCD ↓ Cluster ↓ Secret优点Git 中存储密文GitOps 友好使用简单缺点私钥保存在集群集群迁移复杂多集群管理麻烦适合ArgoCDArgoCD 是一个基于 GitOps 模式 的 Kubernetes 持续交付CD工具主要用于自动化管理 Kubernetes 集群中的应用部署与配置同步以 Git 为唯一可信源FluxGitOps 场景为什么需要 Sealed Secrets在传统的 Kubernetes 部署中Secrets 是 base64 编码的并不是加密的。如果直接将 Secret YAML 文件提交到 Git 仓库任何有仓库访问权限的人都能看到敏感信息如数据库密码、API 密钥等。Sealed Secrets 就是为了解决这个问题而设计的。完整工作流程详解1. 本地加密阶段开发者操作# 1. 首先创建一个普通的 Secret 文件catsecret.yamlEOF apiVersion: v1 kind: Secret metadata: name: my-secret namespace: default data: password:$(echo-nmy-super-secret-password|base64)EOF# 2. 使用 kubeseal 命令加密kubesealsecret.yamlsealed-secret.yaml关键点kubeseal会从 Kubernetes 集群获取公钥用这个公钥加密 Secret 的内容生成的sealed-secret.yaml可以安全地提交到 Git生成的文件类似apiVersion:bitnami.com/v1alpha1kind:SealedSecretmetadata:name:my-secretnamespace:defaultspec:encryptedData:password:AgBy3i4OJSWKPiTySYZZA9rO43cGDEq...template:metadata:name:my-secretnamespace:default2. Git 存储阶段sealed-secret.yaml → Git 仓库安全性Git 中只存储加密后的密文没有私钥任何人包括 Git 仓库管理员都无法解密可以像普通代码一样进行代码审查、版本控制3. 部署阶段GitOps 工具Git 仓库 ↓ (通过 ArgoCD/Flux 监控) Kubernetes 集群 ↓ (Sealed Secrets 控制器监听) SealedSecret 资源4. 解密阶段集群内部SealedSecret 资源 ↓ (集群内的 Sealed Secrets 控制器) 自动解密 ↓ 生成原始 Secret核心机制集群中运行一个 Sealed Secrets控制器该控制器持有私钥这个私钥永远不离开集群当检测到新的 SealedSecret 时控制器用私钥解密自动生成对应的 Kubernetes Secret为什么这种设计是安全的安全边界划分开发者机器有公钥可以加密但无法解密Git 仓库只有密文没有任何解密能力Kubernetes 集群持有私钥可以解密但私钥永不外泄权限控制开发者只需要权限创建 SealedSecret 资源他们不需要直接访问 Secret 资源集群管理员控制私钥的生命周期与传统方法的对比传统方式不安全Secret (明文base64) → Git → ArgoCD → Secret❌ 问题Git 中存储的是可逆的 base64 编码等同于明文Sealed Secrets 方式Secret → kubeseal (加密) → SealedSecret (密文) → Git → 集群 (解密) → Secret✅ 优势Git 中只有真正的加密数据无法被解密多集群管理问题你提到的缺点确实存在问题场景每个集群有自己独立的密钥对同一个 SealedSecret 不能在多个集群使用集群迁移时旧的 SealedSecret 无法在新集群解密解决方案使用相同密钥在多个集群间同步私钥有安全风险范围策略使用--scope参数指定作用范围kubeseal--scopecluster-widesecret.yamlsealed-secret.yaml命名空间管理为每个环境dev/staging/prod使用不同的集群实际使用示例开发者日常流程# 1. 更新敏感配置echonew-password|kubectl create secret generic db-secret\--dry-runclient --from-filepassword/dev/stdin-oyamlsecret.yaml# 2. 加密kubeseal --controller-namesealed-secretssecret.yamlsealed-secret.yaml# 3. 提交到 Gitgitaddsealed-secret.yamlgitcommit-mUpdate database passwordgitpush为什么适合 GitOps声明式配置SealedSecret 是声明式的 Kubernetes 资源版本控制所有变更都有 Git 历史记录自动化ArgoCD/Flux 可以自动同步和部署审计追踪谁在何时修改了什么密钥一目了然环境一致性不同环境使用相同的部署流程总结Sealed Secrets 的核心价值在于将敏感数据的加密责任从人类转移到了系统。开发者不需要记住复杂的加密流程只需要一个简单的命令运维人员不需要担心 Git 仓库泄露导致的敏感信息泄露安全团队可以确信私钥始终在受控的集群环境中。虽然它有私钥管理、多集群支持等挑战但在大多数中小型团队的 GitOps 实践中它仍然是目前最实用、最安全的秘密管理方案之一。4. External Secrets Operator (ESO)近几年最流行的方案之一。项目External Secrets Operator架构AWS Secrets Manager HashiCorp Vault Azure Key Vault Google Secret Manager ↓ External Secrets Operator ↓ Kubernetes Secret示例apiVersion:external-secrets.io/v1beta1kind:ExternalSecretspec:secretStoreRef:name:vaultdata:-secretKey:passwordremoteRef:key:prod/db/password同步后Vault ↓ ESO ↓ Secret优点Secret 不进入 Git支持多种 Secret Backend云原生生态成熟GitOps 友好缺点Secret 最终仍会生成 K8s Secret需要额外 Operator适合大多数企业生产环境目前很多团队已经把 ESO 作为默认方案。5. HashiCorp Vault业界最知名的 Secrets 管理平台。HashiCorp Vault架构Application ↓ Vault Agent ↓ Vault ServerVault 可以存储 Secret动态生成数据库账号动态生成云账号自动轮换密码例如App ↓ 请求 PostgreSQL 凭证 ↓ Vault ↓ 返回临时账号 ↓ 30分钟后自动失效优点企业级支持动态 Secret完整审计日志细粒度权限控制缺点运维复杂学习成本高高可用部署较重适合金融大型企业高安全场景6. Vault Agent InjectorVault 在 Kubernetes 中最经典的落地方式。工作流程Pod 创建 ↓ Admission Webhook ↓ 注入 Vault Agent Sidecar ↓ 从 Vault 拉取 Secret ↓ 写入共享 VolumePodannotations:vault.hashicorp.com/agent-inject:true最终Vault ↓ Agent ↓ tmpfs ↓ Application优点Secret 不经过 GitSecret 不写入 etcd支持动态更新缺点每个 Pod 多一个 Sidecar资源开销较大7. Secrets Store CSI DriverContainer Storage Interface容器存储接口目前云厂商最推荐的方案之一。项目Secrets Store CSI Driver架构AWS Secrets Manager Azure Key Vault Vault GCP Secret Manager ↓ CSI Driver ↓ Pod VolumePodvolumeMounts:-name:secrets-store挂载后/mnt/secrets/password优点Secret 不进入 etcd不创建 Kubernetes Secret原生 CSI 生态自动轮换支持较好缺点应用需读取文件兼容性依赖 Provider适合云原生环境安全要求较高场景8. 云厂商托管方案各大云基本都有自己的 Secret 服务云厂商服务Amazon Web ServicesAWS Secrets ManagerGoogle CloudGoogle Secret ManagerMicrosoftAzure Key VaultAlibaba CloudAlibaba Cloud KMS通常配合ESOCSI Driver使用。演进路线很多团队都会经历类似路径阶段1 K8s Secret 阶段2 K8s Secret etcd Encryption 阶段3 Sealed Secrets 阶段4 External Secrets Operator 阶段5 Vault / 云 Secret Manager 阶段6 Vault CSI Driver 或 Cloud Secret Manager CSI Driver当前主流推荐如果是 2026 年的新项目个人项目 / 小团队K8s Secret etcd Encryption足够。中大型企业External Secrets Operator AWS Secrets Manager或者External Secrets Operator Vault这是目前最常见的组合。高安全要求Vault Secrets Store CSI Driver这样 Secret 可以做到Git 中没有 etcd 中没有 镜像中没有仅在 Pod 运行期间以内存文件形式存在是 Kubernetes Secret 管理体系中安全性较高的一种实现方式。