每个 Kubernetes 集群都附带一个内置的“Secret”对象。看起来很安全。感觉就像安全一样。这不是安全。
默认情况下,Kubernetes Secret 只是存储在 etcd 中的一个 base64 编码的字符串——任何具有集群访问权限的人都可以读取,并且可以使用一行代码轻松解码:echo "c2VjcmV0" | base64 -d。除非您明确启用静态加密(大多数团队都没有),否则您的数据库密码、API 令牌和 TLS 私钥在集群的控制平面数据存储中未加密。将包含“Secret”的 Kubernetes 清单提交给 Git,该凭证将永远存在于存储库的历史记录中。
这就是新一代秘密管理工具的出现来解决的问题——到 2026 年,生态系统已经显着成熟。本指南涵盖了 Kubernetes 环境中管理机密的六种最重要的工具:它们做什么、不做什么以及哪一个适合您团队的成熟度级别。
相关阅读: 如果您担心 CI/CD 管道泄露机密,请参阅我们的最佳 CI/CD 管道工具综述。有关更广泛的容器安全情况,请查看我们的漏洞扫描工具指南。
为什么 Kubernetes 默认 Secret 达不到要求
在深入研究工具之前,有必要准确了解 Kubernetes Secrets 所缺乏的内容,因为了解差距可以让您选择正确的解决方案。
默认情况下不进行静态加密。 etcd 将 Kubernetes Secret 存储为 base64,未加密。启用静态加密 是一个集群级配置步骤,托管 Kubernetes 提供程序(EKS、GKE、AKE)以不同的方式处理,并且许多自管理集群完全跳过它。
没有秘密轮换。 Kubernetes Secret 没有内置机制可以知道其支持凭证已更改。您在外部轮换数据库密码,并且您的 Pod 会继续使用旧密码,直到您手动更新 Secret 并重新启动受影响的 Pod。
没有秘密访问的审核日志。 标准 Kubernetes 审核日志记录秘密对象修改,但大多数配置不会记录单独的读取 — 这意味着您无法回答“哪个服务何时访问了此令牌?”
设计上对 Git 怀有敌意。 标准建议是“永远不要将 Secrets 提交给 Git”。但在以一切皆代码为目标的 GitOps 世界中,这是一个维护起来很痛苦的例外。
RBAC 作为一种钝器。 Kubernetes RBAC 允许您在命名空间级别授予或拒绝对 Secret 对象的访问。它无法表达“服务 A 可以读取秘密 X 但不能读取秘密 Y”或“此秘密将在 24 小时内过期”。
这些都不是放弃 Kubernetes 的理由——它们是在其之上使用专用秘密管理工具的理由。
TL;DR — 功能比较
| 工具 | 静态加密 | 动态秘密 | 审核日志 | K8s原生 | 多云 | 定价 |
|---|---|---|---|---|---|---|
| HashiCorp 金库 | ✅ | ✅ | ✅ | ⚠️(通过代理) | ✅ | OSS 免费 / HCP 付费 |
| 外部秘密运营商 | ✅(通过后端) | ✅(通过后端) | ✅(通过后端) | ✅ | ✅ | 免费/开源软件 |
| 密封的秘密 | ✅ | ❌ | ❌ | ✅ | ❌ | 免费/开源软件 |
| AWS 秘密管理器 | ✅ | ✅ | ✅ | ⚠️(通过 ESO/CSI) | ❌(仅限 AWS) | 按秘密定价 |
| 多普勒 | ✅ | ❌ | ✅ | ✅(操作员) | ✅ | 免费 → 付费等级 |
| 内部 | ✅ | ✅ | ✅ | ✅(操作员) | ✅ | OSS/云付费 |
⚠️ = 需要额外组件
1. HashiCorp Vault — 企业机密的黄金标准
HashiCorp Vault 是衡量其他所有秘密管理工具的基准。它已经在企业环境中经过了近十年的考验,其功能集反映了这种深度。
Vault 的核心功能是动态秘密——按需生成并自动过期的凭证。 Vault 不是存储静态 PostgreSQL 密码,而是为每个请求服务生成唯一的用户名/密码对,在可配置的租用期限(例如一小时)内有效。当租约到期时,凭证将被撤销。这消除了整个类别的凭证蔓延,并使违规遏制变得更加容易。
对于 Kubernetes,Vault Agent Injector 或 Vault Secrets Operator 是集成路径。注入器作为一个变异的 Webhook 运行,自动将 Vault 代理附加到您的 pod 中,该代理使用 pod 的 Kubernetes 服务帐户对 Vault 进行身份验证,并将机密写入共享内存卷。 Vault Secrets Operator (VSO) 是一种较新的方法,它将 Vault Secrets 同步到本机 Kubernetes Secret 对象中——操作员更熟悉,但代价是 etcd 中短暂存在的机密。
Vault 的秘密引擎涵盖了令人印象深刻的范围:
- 数据库凭据(PostgreSQL、MySQL、MongoDB 等)
- AWS、GCP、Azure 动态凭证
- PKI和TLS证书生成
- SSH证书签名
- Kubernetes服务帐户令牌
Vault 擅长的地方: 动态凭证、细粒度的访问策略、全面的审核日志和成熟的插件生态系统。如果您需要合规级秘密管理并完整跟踪谁访问过什么时间,Vault 通常是唯一合理的选择。
需要注意的事项: Vault 具有操作复杂性。在高可用性模式下运行它需要仔细关注存储后端(Raft 现在是推荐选择)、解封过程和升级路径。学习曲线是真实的。平台工程时间预算。
定价: 开源版本是免费的,可以满足大多数需求。 HashiCorp 云平台 (HCP) Vault 是一种托管产品,其定价基于集群时间和秘密操作。 2023 年的 BSL 许可证变更 导致了 Terraform 的 OpenTofu 分叉,但 Vault 的分叉等效项 (OpenBao) 仍在成熟。
📚 推荐阅读:Andrew Martin 和 Michael Hausenblas 的 Hacking Kubernetes — 出色地涵盖了 Kubernetes 攻击面,包括秘密泄露场景。
2. 外部 Secrets Operator (ESO) — K8s 原生集成层
External Secrets Operator 采取了根本不同的架构立场:它本身不是一个秘密存储,而是 Kubernetes 和您已有的任何外部存储之间的桥梁。 ESO 将来自 AWS Secrets Manager、GCP Secret Manager、Azure Key Vault、HashiCorp Vault、1Password、Doppler 以及不断增长的其他后端列表的密钥同步到本机 Kubernetes Secret 对象中。
核心抽象是“ExternalSecret”自定义资源:
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: database-credentials
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secrets-manager
kind: ClusterSecretStore
target:
name: db-creds
data:
- secretKey: password
remoteRef:
key: production/db/password
ESO 监视此资源,从 AWS Secrets Manager(或其他位置)获取密钥,并创建标准 Kubernetes 密钥。您的应用程序像任何其他 Kubernetes Secret 一样读取“db-creds”——无需更改代码。当 refreshInterval 勾选时,ESO 会自动重新获取并更新 Secret。
为什么 ESO 在 2026 年如此受欢迎: 它与现有投资配合良好。您的组织已经拥有 AWS Secrets Manager(或 Vault 或 GCP Secret Manager) - ESO 只是使这些密钥可以在 Kubernetes 中使用,而无需更改您的应用程序代码或现有的密钥轮换工作流程。
ESO 或 Vault Secrets Operator? 如果您正在运行 Vault,则 VSO 具有更紧密的 Vault 特定集成(Vault 动态机密、Vault PKI)。如果您使用云提供商的本机秘密存储,ESO 是更干净的选择。许多团队同时运行这两种方式:ESO 用于云存储的静态机密,VSO 用于 Vault 管理的动态凭证。
定价: ESO 是免费且开源的 (Apache 2.0),由具有强大社区支持的 CNCF 沙箱项目维护。
3. 密封的秘密 — GitOps 友好的加密秘密
Bitnami 的 Sealed Secrets 解决了一个特定问题:如何在 Git 中存储 Kubernetes Secret 清单而不存储实际的明文?答案是非对称加密。
Sealed Secrets 控制器在您的集群中运行并持有私钥。 “kubeseal” CLI 使用集群的公钥加密 Kubernetes Secret 清单,生成“SealedSecret” CRD。这个加密的清单可以安全地提交到 Git — 只有集群的私钥可以解密它,并且只能在该特定集群中解密(默认情况下,密文绑定到命名空间 + 名称)。
# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
--from-literal=password=s3cr3t \
--dry-run=client -o yaml | \
kubeseal --format=yaml > db-creds-sealed.yaml
# This file is safe to commit
git add db-creds-sealed.yaml
当您将“SealedSecret”应用于集群时,控制器会对其进行解密并创建相应的“Secret”对象。
Sealed Secrets 擅长什么: GitOps 工作流程。如果您使用 Argo CD 或 Flux 并希望每个集群资源(包括机密)以声明方式存储在 Git 中,那么 Sealed Secrets 非常适合该模型。除了集群内控制器之外,它需要零外部依赖性。
它不做什么: 标准 Kubernetes 事件之外的轮换、动态凭证或审核日志记录。 Sealed Secrets 是一个 Git 存储解决方案,而不是一个完整的秘密管理平台。如果您的密码发生更改,您需要重新加密并再次提交。
私钥备份至关重要。 如果您丢失了控制器的私钥,您将无法解密您的密封秘密。将“sealed-secrets-key”机密备份到单独的安全位置。
定价: 完全免费且开源 (Apache 2.0)。
4.AWS Secrets Manager 与 Kubernetes
如果您的工作负载主要在 EKS 上运行(或大量连接到 AWS 服务),那么 AWS Secrets Manager 与 Secrets Store CSI Driver 或外部 Secrets Operator 搭配使用是很自然的选择。您可以将机密保存在 AWS 的托管、加密、审计记录存储中,并在需要时将其拉入 Kubernetes。
Secrets Store CSI Driver (SSCSID) 是 CNCF 维护的方法:秘密通过 CSI 卷作为文件直接安装到 pod 中,而不会作为 Kubernetes Secret 对象写入 etcd。这是安全性最高的路径——秘密存在于 pod 内存中,但不存在于 Kubernetes Secret 存储中。
volumes:
- name: secrets-store
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: aws-secrets
AWS Secrets Manager 的本机功能包括支持服务的自动轮换(RDS、Redshift、DocumentDB 以及通过 Lambda 进行自定义轮换)、跨账户访问以及用于合规性审计跟踪的深度 CloudTrail 集成。
成本考虑: AWS Secrets Manager 按每月每个密钥和每次 API 调用收费。对于拥有许多小秘密的大型舰队,成本可能会增加。请参阅我们的云成本优化指南,了解管理与秘密相关的 AWS 支出的策略。
最适合: EKS 原生团队已经投资于 AWS 生态系统,需要紧密的 IAM 集成和原生 RDS 凭证轮换。
5. Doppler — 开发者优先的 SaaS 秘密平台
Doppler 采用 SaaS 优先的方法,优先考虑开发人员体验而不是操作复杂性。您可以在 Doppler 的 UI(或通过 CLI/API)中定义机密,按环境(开发、登台、生产)组织它们,Doppler Kubernetes 操作员会自动将它们同步到 Kubernetes Secrets 中。
操作员轮询 Doppler 以了解更改并更新相应的 Kubernetes Secret,可以选择在 Secret 更改时触发 pod 重新启动。安装程序是单个 Helm 图表安装:
helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator
Doppler 的闪光点: 本地开发和 CI/CD 与 Kubernetes 集成。 Doppler CLI 完全替换了环境文件(“doppler run – your-command”),在本地、CI 和生产环境中提供相同的秘密。对于 CI/CD 管道,Doppler 与 GitHub Actions、CircleCI 等的本机集成消除了将机密复制到管道环境变量中的需要。
多普勒不涵盖的内容: 动态数据库凭证。 Doppler 是一个静态秘密存储,具有版本历史记录和审核日志记录 - 它不是像 Vault 这样的秘密生成引擎。
定价: Doppler 为小型团队提供免费套餐。付费计划添加了 SSO、访问请求和合规性功能。检查 Doppler 定价页面 了解当前等级(定价更改;在预算之前进行验证)。
6. Infisical — 开源 Vault 替代方案
Infisical 是 Vault/Doppler 双寡头最强大的开源挑战者。它提供了 Web UI、CLI、SDK 和 Kubernetes Operator——可部署自托管或作为云服务使用。
Infisical 在 2024 年添加了动态机密支持,目标是类似于 Vault 数据库机密引擎的数据库凭证生成。 Infisical Kubernetes 操作员将“InfisicalSecret” CRD 同步到本机 Kubernetes Secret,并具有可配置的刷新间隔。
对于需要 SaaS 级用户体验(Web 仪表板、访问请求工作流程、审核日志)但由于合规性要求而无法使用外部 SaaS 的团队来说,Infisical 自托管非常有吸引力。它比 Vault 更容易操作,并且具有对开发人员更友好的入门体验。
定价: 开源核心是免费的。云托管版本具有免费套餐和高级功能的付费计划。自托管企业许可证适用于合规性要求较高的环境。
📚 要更深入地了解 Kubernetes 安全架构:Amazon 上的 Kubernetes 安全性和可观察性 涵盖了一个内聚框架中的秘密、RBAC、网络策略和运行时安全性。
实施技巧
从静态加密开始。 在添加任何其他工具之前,请启用 Kubernetes etcd 静态加密。对于托管集群,这通常是一个复选框。对于自我管理集群,请遵循官方指南。这会立即提高您的安全基线。
对 Secrets 采用最小权限 RBAC。 审核哪些服务帐户对 Secret 对象具有“get”、“list”或“watch”权限。许多 Helm 图表中的默认服务帐户是过度配置的。在旋转到外部存储之前收紧 RBAC。
**尽早计划您的秘密命名约定。**秘密会快速扩散。一致的层次结构(“{env}/{service}/{credential-type}”)使所有工具的自动化、RBAC 策略和轮换工作流程变得更加简单。
不要跳过秘密轮换测试。 无论您选择哪种工具,请在需要之前运行轮换演练。验证您的应用程序是否可以在不停机的情况下获取新凭证。使用 Vault 或 ESO 的动态机密比手动更新静态机密要容易得多。
监控秘密蔓延。 随着平台的发展,秘密会不断积累。将机密管理报告集成到您的平台工程仪表板中。请参阅我们的 Kubernetes 监控工具指南,了解可以跟踪秘密访问模式的可观察性工具。
哪个工具适合哪个团队?
小团队、云原生 (AWS/GCP/Azure): 从连接到云提供商的本机秘密存储的外部 Secrets Operator 开始。最小的运营开销、可靠的审计集成、免费。
GitOps 第一团队(Argo CD / Flux): GitOps 存储配置的密封秘密,与 ESO 相结合,用于敏感的运行时凭证,这些凭证甚至不应该在 Git 中加密。
具有合规性要求(SOC 2、PCI、HIPAA)的企业: HashiCorp Vault — 自托管 Raft 集群或托管的 HCP Vault。审计日志、动态凭证和细粒度的策略引擎很难在其他地方复制。
注重开发人员体验的混合环境(K8s + 本地 + CI/CD): Doppler 用于跨环境的统一 DX,或者如果数据驻留很重要,则使用 Infisical 自托管。
**管理多集群环境的大型平台团队:**外部 Secrets Operator 作为 K8s 端抽象层,由 Vault 或云原生存储支持。将事实来源集中在一个存储中,同时使用 ESO 作为跨集群的通用适配器,这是 2026 年经过充分验证的模式。
相关: 有关 AI 编码工具引入 Kubernetes 清单和 CI/CD 管道的安全风险,请参阅我们的 2026 年 vibe 编码安全风险 指南。
## 常问问题
<脚本类型=“应用程序/ld+json”> { “@context”: “https://schema.org”, “@type”: “常见问题解答页面”, “主要实体”:[ { “@type”: “问题”, “name”: “Kubernetes Secrets 默认加密吗?”, “接受答案”:{ “@type”: “回答”, “text”: “否。Kubernetes Secret 默认情况下采用 Base64 编码,这是编码而不是加密。除非您在集群级别显式配置静态加密,否则数据存储在 etcd 中而不进行加密。EKS、GKE 和 AKS 等托管 Kubernetes 服务提供可选的 etcd 加密,但必须启用它。始终验证集群的加密配置,并考虑使用外部机密管理工具来处理敏感凭证。” } }, { “@type”: “问题”, “name”: “封密者和对外密者有什么区别?”, “接受答案”:{ “@type”: “回答”, “text”: “Sealed Secrets 加密 Kubernetes Secret 清单,以便它们可以安全地提交到 Git。这是一个 Git 存储解决方案 - 秘密存在于 Git 中(加密)并由集群内控制器解密。External Secrets Operator 是一个桥梁,可以从外部存储(AWS Secrets Manager、HashiCorp Vault、GCP Secret Manager 等)获取秘密并从中创建 Kubernetes Secret 对象。它们解决了不同的问题:GitOps 的密封秘密工作流程,ESO 用于从外部管理系统提取实时机密。” } }, { “@type”: “问题”, “name”: “HashiCorp Vault 中的动态秘密是什么以及它们为何重要?”, “接受答案”:{ “@type”: “回答”, “text”: “动态机密是 Vault 按需生成的凭证,而不是静态存储的凭证。当服务请求 PostgreSQL 凭证时,Vault 会创建一个唯一的用户名和密码对,授予其适当的数据库权限,并设置到期时间(“租约”)。当租约到期时,Vault 会自动撤销凭证。这意味着没有长期密码可供窃取,并且每个服务实例都会获得自己唯一的凭证 - 限制爆炸半径(如果有)动态机密可用于数据库、AWS IAM、GCP 服务帐户、Azure 服务主体、SSH 等。” } }, { “@type”: “问题”, “name”: “如何将 AWS Secrets Manager 与 Kubernetes(非 EKS)集成?”, “接受答案”:{ “@type”: “回答”, “text”: “最可移植的方法是使用 AWS ClusterSecretStore 的外部 Secrets Operator。您可以使用 Secretsmanager:GetSecretValue 权限创建 IAM 用户或角色,使用这些凭证配置 ESO ClusterSecretStore(或将 IRSA 用于 EKS),然后定义引用您的 AWS Secrets Manager 路径的ExternalSecret 资源。ESO 按您配置的时间间隔将值同步到 Kubernetes Secret 对象中。特别是对于 EKS,IRSA(服务账户的 IAM 角色)允许 Pod 级别无需静态凭证的 IAM 身份验证。” } }, { “@type”: “问题”, “name”: “我应该使用 Doppler 还是 HashiCorp Vault 进行 Kubernetes 机密管理?”, “接受答案”:{ “@type”: “回答”, “text”: “Doppler 和 Vault 针对不同的需求。Doppler 擅长开发人员体验 — 简单的 UI、本机 CI/CD 集成以及跨本地开发、登台和生产管理机密的统一方式。Vault 擅长满足企业安全要求 — 动态机密生成、细粒度策略引擎、全面的审计日志记录和多云机密后端。对于开发人员生产力最重要的中小型团队,Doppler 通常是更快的路径。对于合规性要求较高的团队对于需要动态凭证和完整审核跟踪的环境(SOC 2、PCI DSS、HIPAA),Vault 是更可靠的选择。” } }, { “@type”: “问题”, “name”: “如何防止机密泄露到容器日志或环境变量中?”, “接受答案”:{ “@type”: “回答”, “text”: “有几种做法有帮助:首先,更喜欢将机密安装为文件(通过卷安装)而不是环境变量 — 环境变量可以通过 /proc、调试端点或故障转储公开。其次,使用 Secrets Store CSI 驱动程序直接从外部存储安装机密,而根本不需要将它们写入 etcd。第三,配置日志记录堆栈以清除已知的机密模式。第四,使用具有“secretSyncOnly”模式的 Vault Agent 或 ESO,以便在执行期间不会记录机密。最后,在代码到达您的存储库之前,使用 Trivy 的秘密扫描器或 GitLeaks 等工具扫描 CI/CD 中的意外秘密提交。” } }, { “@type”: “问题”, “name”: “对于小团队来说最好的 Kubernetes 秘密管理工具是什么?”, “接受答案”:{ “@type”: “回答”, “text”: “对于小型团队来说,最好的起点通常是连接到云提供商的本机秘密存储(AWS Secrets Manager、GCP Secret Manager 或 Azure Key Vault)的外部 Secrets Operator。这种方法具有最小的运营开销 — ESO 控制器是唯一需要维护的附加组件 — 并且通过云提供商的内置工具立即为您提供静态加密、审核日志记录和秘密轮换。如果您的团队还需要良好的本地开发体验,Doppler 的免费套餐会添加统一的秘密 UI以及跨本地、CI 和 Kubernetes 环境运行的 CLI。” } } ] } </脚本>
Kubernetes Secrets 默认加密吗?
不会。Kubernetes Secret 默认采用 base64 编码——编码,而不是加密。除非您明确启用静态加密,否则数据存储在 etcd 中时不会加密。始终验证您的集群配置并考虑用于生产工作负载的外部机密管理工具。
封密和外密干员有什么区别?
Sealed Secrets 对 Secret 清单进行加密以实现安全的 Git 存储 - 这是一个 GitOps 解决方案。外部 Secrets Operator 从外部存储(Vault、AWS Secrets Manager 等)获取实时密钥,并从中创建本机 Kubernetes 密钥。它们解决不同的问题并且经常一起使用。
什么是动态秘密以及它们为何重要?
动态机密是按需生成并自动过期的凭证,而不是无限期存储的静态密码。 HashiCorp Vault 是 Kubernetes 动态机密的主要来源。如果动态凭证被泄露,它会按照自己的时间表过期。与长期静态秘密相比,这极大地限制了破坏爆炸半径。
我应该为 Kubernetes 使用 Doppler 还是 HashiCorp Vault?
Doppler 凭借开发者经验和快速采用而获胜。 Vault 在企业合规性方面获胜 - 动态凭证、精细审核日志和细粒度策略。对于中小型团队,多普勒通常是更快的路径。对于 SOC 2、PCI DSS 或 HIPAA 环境,Vault 通常是更可靠的选择。
如何防止机密泄漏到容器日志中?
将机密挂载为文件而不是环境变量(环境变量可以通过“/proc”和调试端点公开)。使用 Secrets Store CSI 驱动程序完全绕过 etcd。使用 Trivy 的秘密扫描器等工具扫描 CI/CD 管道中的意外秘密提交 - 请参阅我们的漏洞扫描工具指南 了解设置详细信息。
对于小型 Kubernetes 团队来说,最好的秘密管理工具是什么?
从由云提供商的本机秘密存储支持的外部秘密操作员开始。最小的操作开销,可靠的审计日志记录,免费。如果您还想要统一的开发/CI/生产机密体验,请添加 Doppler 的免费套餐。
如何将 AWS Secrets Manager 与 Kubernetes 集成?
将外部 Secrets Operator 与指向 AWS Secrets Manager 的 ClusterSecretStore 结合使用。在 EKS 上,使用 IRSA(服务帐户的 IAM 角色)进行 Pod 级 IAM 身份验证 - 无需静态凭证。在非 EKS 集群上,使用 IAM 用户与 Secretsmanager:GetSecretValue 范围为您的特定秘密 ARN。