Kubernetes Secrets加密困惑：Secrets Manager与静态加密方案对比

一、Vault和Sealed Secrets的核心价值 #

你提到静态加密（Encryption at rest）能在集群遭攻击时保护Secrets，但Vault和Sealed Secrets解决的是静态加密覆盖不到的场景，核心价值体现在：

1. Sealed Secrets：GitOps场景下的安全Secrets交付 #

• 解决GitOps痛点：在GitOps工作流中，配置文件需存入Git仓库，但明文Secrets绝对不能提交。Sealed Secrets允许你把**加密后的Secrets（SealedSecret CR）**安全存入Git，只有目标Kubernetes集群内的控制器能解密为普通Secret，避免了明文Secrets在版本控制中泄露的风险——这是静态加密完全覆盖不到的环节（静态加密仅保护etcd内的数据，无法管控Git中的Secrets）。
• 细粒度解密权限：Sealed Secrets支持按命名空间、控制器权限控制解密范围，即便Git仓库泄露，攻击者没有集群内的解密密钥也无法还原明文Secrets；而静态加密是集群级别的，一旦etcd的加密密钥泄露，所有Secrets都会暴露。

2. Vault：集中化动态Secrets管理与全生命周期控制 #

• 动态生成敏感凭据：Vault可动态生成临时数据库访问密钥、云服务令牌、Kubernetes Service Account令牌等，用完自动回收，从根源上避免静态Secret长期存在被泄露的风险——静态加密和Sealed Secrets仅处理静态凭据，无法实现动态轮换。
• 跨环境集中管控：若架构包含多Kubernetes集群、云服务、传统服务，Vault可作为单一Secrets管理入口，统一配置访问策略、审计日志，比在每个集群单独配置静态加密高效得多。
• 灵活注入方式：除了你提到的Vault Secrets Operator生成普通Secret，Vault还支持Agent注入模式——直接在Pod启动时将临时Secrets注入容器，不会在集群内留下持久化的Secret，进一步降低泄露风险。

二、Azure Key Vault凭据循环问题的解决方案 #

你担心的"存凭据到Secret会被exec获取，存其他服务又要新密钥"的循环，可通过无凭据的身份认证打破：

1. Azure AD Pod Identity/Workload Identity #

• 给Pod绑定Azure AD托管身份（Pod Identity），或把Kubernetes Service Account与Azure AD身份绑定（Workload Identity），Pod无需存储任何静态凭据（如AZURE_TENANT_ID、CLIENT_ID），直接通过自身身份向Azure AD请求访问令牌，再用令牌访问Key Vault。
• 这种方式下，身份凭据由Azure自动轮换，无需手动管理，攻击者即使exec进Pod，也拿不到长期有效的敏感密钥。

2. Secrets Store CSI Driver + Azure Key Vault Provider #

• 用CSI Driver直接将Azure Key Vault中的Secrets挂载到Pod的文件系统或环境变量中，Pod无需编写SDK调用逻辑，直接使用挂载的敏感数据。
• CSI Driver的身份认证依赖节点托管身份或Pod身份，无需在Kubernetes中存储任何访问Key Vault的凭据，完全避免静态Secret的泄露风险。

3. 最小权限原则（静态凭据兜底方案） #

若必须使用静态凭据（不推荐），需严格限制Secret的访问权限：

• 用RBAC仅允许特定Service Account读取该Secret；
• 禁止Pod以root用户运行，限制exec进入容器的权限；
• 定期轮换凭据，降低泄露后的影响范围。

内容的提问来源于stack exchange，提问作者Vincenzo