External Secrets Operator 暂停后何去何从

External Secrets Operator 已暂停。接下来是什么？

发布于 2025 年 8 月 27 日，星期三

External Secrets Operator (ESO) 是一个开源服务，它从 secrets managers（例如 AWS Secrets Manager）中提取信息，并自动将这些值注入为 Kubernetes Secrets。因此，ESO 充当了 Kubernetes 与第三方服务之间一个巧妙的桥梁。

不幸的是，在 2025 年 8 月 13 日，ESO 团队 宣布 他们将正式暂停后续发布，直到他们能够重建 ESO 团队。ESO 表示，他们的团队规模过小，无法以可持续的方式满足用户所要求的发布节奏。他们暂停了所有新功能、补丁和容器镜像；也暂停了支持。话虽如此，他们仍会继续合并社区提交的 PR。

ESO 曾是一个很棒的 OSS 项目，被许多关键组织使用，用于在两个独立的 secrets managers 之间提供一个轻量级解决方案。我们希望 ESO 团队能够组建一个更适合这项工作的团队；然而，许多 ESO 用户也 understandably 地担心这个项目会失去动力并逐渐消亡。虽然我们强烈希望情况不会如此，但我们想分享一下你如何从 ESO 切换到像 Infisical 这样的商业开源平台。

但首先，让我们先回顾一下 ESO 是什么，以及他们为什么暂停开发。然后，我们将讨论 Infisical 是如何工作的。

什么是 External Secrets Operator？

External Secrets Operator (ESO) 是一个 Kubernetes operator，用于连接 Kubernetes 集群与外部 secrets managers，并原生支持 AWS Secrets Manager、Infisical、HashiCorp Vault、Google Secret Manager、Akeyless、Azure Key Vault、Pulumi ESC 等更多服务。

secrets managers 的目标是避免将敏感数据提交到仓库；相反，它们通过字符串引用，并在构建或运行时获取。ESO 不是 一个 secrets manager；相反，它是一个桥梁，从外部 secrets manager 获取数据，并将其与 Kubernetes 原生 secrets 支持同步。

ESO 的目标是让开发者在使用 Kubernetes 的同时，将 secrets 操作整合并标准化到 Kubernetes 之外。外部 secrets managers 提供了强大的技术来保护整个技术栈中的 secrets。例如，secrets manager 可以轮换并动态生成 secrets。它们还会将 secrets 管理与证书管理整合在一起，提供一个用于管理访问参数的统一系统。

简而言之，ESO 将 secret 存储和轮换与 Kubernetes 集群运行时解耦，使开发者能够在 Kubernetes 原生消费的同时保持集中管理。

为什么 ESO 暂停开发？

不幸的是，ESO 由于 burnout 而暂停开发。ESO 团队非常小，只有一名维护者几乎全职在做这个项目。团队承受了来自 ESO 用户的很大压力，这些用户希望他们遇到的问题能够立即得到修复。

ESO 维护者 Gergely Brautigam 说：“人们并不总是尊重我们的时间、我们的努力，或者我们的任何付出”，并补充道：“人们觉得自己有权说‘我在用这个和这个，而且它不能用了，所以修复它’，但事情不是这样运作的。”

这就是许多没有商业支持的独立开源项目所面临的不幸现实：尽管这些项目纯粹是出于公益而存在，独立开发者却被当成一个人员齐备的公司来对待。

尽管公众 多次呼吁 维护者加入该项目，但目前没有证据表明 ESO 接近组建长期团队。不过，我们仍希望他们能够做到，因为 ESO 对于使用两个 package managers 的公司来说，是一个关键的极简解决方案。

ESO 和 Infisical 是彼此的替代方案吗？

ESO 和 Infisical 是不同的开源产品。ESO 是一个桥梁——它将外部 secrets managers（如 Infisical）与 Kubernetes 连接起来。实际上，ESO 有专门的文档 支持 Infisical。

然而，与许多基础的 secrets managers 不同，Infisical 也有 对 Kubernetes 的第一方支持，包括 原生 injector。从这个意义上说，尽管 Infisical 是一个更全面得多的解决方案，但它也是 ESO 的替代方案——前提是开发者将 Infisical 作为他们的 package manager。

让我们来看看 Infisical 如何原生集成到 Kubernetes。然后，我们将讨论如何从 ESO（以及你的 package manager）切换到 Infisical，把 secrets 和 Kubernetes 集成整合到一个单一解决方案中。

Infisical 如何与 Kubernetes 集成？

有几个组件将 Infisical 与 Kubernetes 紧密集成。Infisical 有 multiple 种将 secrets 与 Kubernetes 同步的策略，以适应不同的构建方式。

Infisical Operator

Infisical 提供了一个 Kubernetes Operator（通过 Helm 安装），持续将你的集群与 Infisical 进行协调。

它引入了 CRDs，用于将 secrets 从 Infisical 同步、将 secrets 推送到 Infisical，以及管理动态 secrets。配置后，operator 会保持 Kubernetes 资源处于最新状态，并可触发使用更新后 secrets 的工作负载进行滚动重启。它还支持高级 Go template 转换（带 helper functions）以及用于自托管部署的自定义 CA trust。

连接 Infisical 和 Kubernetes 的 CRD 有三个。

InfisicalSecret CRD

InfisicalSecrets CRD 将 secrets 从 Infisical 同步到 Kubernetes，作为原生 Secret（以及可选的 ConfigMap）资源。可以按 project、environment 或 path 进行范围限定，并递归获取。

InfisicalPushSecret CRD

InfisicalPushSecret CRD 的作用正好相反——它将 Kubernetes Secret 推送到 Infisical 以实现集中管理。它可以覆盖 secrets，也可以删除 secrets。

InfisicalDynamicSecret CRD

InfisicalDynamicSecret CRD 在 Infisical 中为动态 secrets（例如数据库凭据）创建有时效限制的 lease，并将其同步为 Kubernetes Secret。operator 会在过期前续期或轮换，并且可以设置 lease revocation policies。

Kubernetes Agent Injector

另一种策略是使用 Agent Injector，这是一种 mutating admission webhook，它通过注入一个 Infisical Agent 容器，将 secrets 注入到 Pod 中。

Kubernetes CSI

Infisical 还提供了一个 CSI（Container Storage Interface）provider，可与 Secrets Store CSI Driver 配合工作，将 secrets 直接作为文件挂载到 Pods 中，而无需 Kubernetes Secret 对象。这里，开发者定义一个 SecretProviderClass，将 Infisical secrets 映射到文件路径。

如何从 ESO 迁移到 Infisical？

从 ESO 迁移到 Infisical 是一个简单的两步过程。

首先，选择迁移到 Infisical 作为你的 Secrets Manager

将你现有的 secrets 迁移到 Infisical，作为你的中心化 secrets manager。对于某些选项，Infisical 有专门的指南；例如，你可以参考这个资源将 secrets 从 Vault 迁移到 Infisical。

Infisical 是一个 very 高级的 secrets 解决方案，还额外强力支持证书管理、secrets 扫描、特权访问管理等。该平台通常与其他替代方案功能对等；它也比 AWS Secrets Manager 这类僵化的云提供商解决方案灵活得多。

第二，迁移出 ESO，改用 The Infisical Operator、Kubernetes Agent Injector 和 Kubernetes CSI。

从 ESO 切换到 Infisical 意味着选择合适的 Infisical 策略。

Infisical Operator 最适合希望通过 CRDs 在 Kubernetes 内部直接自动同步和管理 secrets 的团队。Kubernetes Agent Injector 非常适合需要在不创建 Kubernetes Secret 对象的情况下直接将 secrets 注入到 Pods 中的场景。Kubernetes CSI 则非常适合将 secrets 作为文件挂载到 Pods 中，尤其是在你想完全避免使用 Kubernetes Secret 对象时。

Mathew Pregasen

Technical Writer, Infisical

twitter github linkedin

从 Infisical 开始使用很简单、很快，而且免费。

• 原文链接： infisical.com/blog/exter...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～