使用 Kubeseal 密封 Kubernetes 密钥

显式面临的痛点

当团队使用 GitOps 工具链管理 Kubernetes 集群时，将配置代码存放至 Git 仓库是一件极其自然的事。然而，这会引发一个核心安全冲突：Git 仓库要求极高的可见性，而敏感数据（如数据库凭据、API 密钥）天生需要被严格隔离。即便配置文件存放在私有仓库中，具备读权限的任何人、任何 CI 流水线也都能看到 plaintext 格式的密码。

一旦明文密钥进入代码提交记录，泄露风险便呈指数级上升。因此，在 DevOps 工作流中，密钥管理的本质不再是单纯的加密存储，而是寻找一种能将安全凭证与底层配置文件无缝结合、且能安全提交至公共或私有版本控制系统的方案。

核心机制解析

Sealed Secrets 通过分离加密与解密的权限解决了上述难题。本技能的核心在于利用 kubeseal 工具，将包含敏感信息的 Kubernetes Secret 清单封装成 Sealed Secret 对象。

工作原理如下：

• 加密过程：通过调用 kubeseal 并传入目标 Secret 清单，工具会获取 Sealed Secrets 控制器的公钥。随后，它会将原本的敏感数据进行非对称加密，生成一个包含 SealedSecret 资源的自定义清单。
• 安全提交：由于加密后的数据仅包含密文和目标集群的标识信息，可以安全地通过 CI/CD 管道提交到 Git 仓库。即便仓库被攻破，攻击者因缺乏控制器的私钥也无法还原数据。
• 解密注入：在集群端，Sealed Secrets 控制器持续监听 SealedSecret 资源。一旦检测到新对象，控制器会利用内置的私钥进行解密，并自动在目标命名空间中生成对应的原生 Secret 资源。

这种设计将解密权限完全限制在目标集群内部，实现了配置管理与密钥分发的完美解耦。

适用场景与边界

虽然该方案显著提升了安全性，但在实际应用中仍需注意其适用范围：

• 依赖控制器高可用：Sealed Secrets 控制器必须持续在线且具备高可用性，否则集群将无法解密并注入新的密钥。
• 初始部署成本：在开始使用前，必须确保集群中已安装 SealedSecret CRDs，且 kubeseal 客户端能够访问到控制器的公钥证书。
• 资源生命周期管理：密钥轮换目前依赖于重新密封并更新 Git 仓库中的清单，由控制器触发更新，这可能不如某些动态密钥管理系统灵活。
• 集群唯一性：密封的密钥通常与特定的集群证书绑定，跨集群复制 Sealed Secret 清单通常无法工作。

综上所述，该技能适合那些需要在 GitOps 流程中处理敏感配置，同时要求对密钥访问路径有极高控制力的技术团队。