文章解释了“秘密蔓延”问题：随着应用、环境和外部服务增多，API 密钥、数据库凭据、证书等敏感信息分散在开发、测试、生产及多种基础设施中，导致配置遗漏、泄露难追踪、轮换撤销低效等风险。作者提出用中心化秘密管理器统一存储、分发、审计和管理 secrets，并介绍其在本地开发、CI/CD 与生产中的接入方式，以及选型时应考虑部署模式、加密能力、功能集与成本。
什么是 secret？
首先，我们需要定义“secret”这个词。在这个语境中，secret 指的是任何敏感数据，例如 API keys、数据库凭证、TLS certificates、加密密钥，以及需要为你的应用/基础设施安全存储和处理的环境变量。
在大多数情况下，secret 允许应用程序访问系统。例如，凭证可能允许应用程序从数据库、S3 等位置读写数据。鉴于 secret 经常用于身份验证和/或授权，它们应该得到妥善保护，避免落入坏人之手，否则这些人可能会利用 secret 获取对关键系统和数据的访问权限。
考虑到这一点，让我们来讨论“secret sprawl”。
什么是 secret sprawl？
术语 secret sprawl 指的是团队无法有效管理分散在其基础设施中的 secret。随着团队在多个环境中部署越来越复杂的服务（例如 development、staging、production），而每个服务又依赖一个或多个外部服务，他们会积累数百个，有时甚至数千个 infrastructure secrets、kubernetes secrets 等。
需要管理大量 secret 会带来显著的安全风险、配置错误，并最终导致失误。从难以保证对 secret 的正确处理和加密，到难以准确定位某个特定 secret 在哪里以及不知道谁有访问权限，再到忘记在软件开发生命周期的不同阶段创建/更新/删除 secret，secret sprawl 会引发许多问题。
下面这些相关场景听起来可能很熟悉：
- 你在 development 中引入了一个新的环境变量，却忘了通知团队中的其他开发者这次更新。他们开始开发后，才发现应用程序因为缺少该变量而崩溃，随后又因排查缺失的值而浪费了宝贵时间。
- 你在 development 和 staging 中引入了一个新的环境变量，却忘了把它添加到 production。重新部署 production 服务后，你发现服务对所有人都失效了。
- 某个 secret 在你的开发周期中的某处，甚至在多个位置意外泄露了，而你意识到自己并不具备追溯事情经过并据此采取行动的能力。这包括 secret 是在哪里、何时以及如何泄露的，以及是谁泄露的。
- 某个 secret 意外泄露了，你手忙脚乱地想要及时吊销它，因为它在你复杂的基础设施中具体位于哪里并不清楚，这就是 sprawl。除此之外，你还会发现自己为了轮换这个 secret 而浪费了宝贵时间。
总的来说，secret sprawl 使得有效管理 secret 变得困难，从而带来不必要的风险和麻烦。
解决 secret sprawl 的方案
要解决 secret sprawl，你需要中心化你的 secrets management，也就是为你基础设施中的 secret 提供一个统一的视图和管理入口。更具体地说，你需要使用一个专门的工具，称为 secret manager，来存储 secret，并简化向应用程序和基础设施交付 secret 的过程。借助它，你可以在应用程序中存储和查询敏感数据。
你可以把 secret manager 想象成一种特殊的安全数据库，数据受到严格控制、加密并被审计。虽然其核心功能是存储和分发 secret，但 secret manager 还具有独特的 secret-specific 功能，例如生命周期管理能力，包括版本控制、轮换、吊销，甚至 dynamic secrets。顺带一提，有些 secret manager 允许你附加不同的“存储后端”。例如，你可以将它们配置为对接 PostgreSQL、MySQL、S3 等。
使用 secret manager 有助于解决上一节所描述的问题，并且是任何安全体系的重要组成部分。最明显的是，它确保你整个开发周期中的服务在任何时候都能获得正确的 secret，这也包括开发者经常使用 .env 文件作为替代方案的本地开发。同时，它不仅提供所有 secret 管理活动的详细记录，使你能立即了解任何事件的完整经过，还在需要时提供一种简单机制来即时轮换 secret。
我如何将它融入/实现到我的 stack 中？
作为一种旨在服务整个开发周期的工具，secret manager 应该位于你的 stack 旁边，并将 secret 从本地开发、CI/CD pipelines 一直到 production 分发到你的基础设施中。开始使用 secret manager 的一般流程通常包括：
- 设置 secret manager：如果使用 AWS secret manager 之类的云服务，这可能涉及选择一个 region；否则，这可能意味着按照步骤在本地自托管一个 secret management solution。在这一步中，你通常会配置访问控制，决定哪些实体应该能够访问 secret manager，并向其中添加 secret。
- 将 secret 获取回你的应用程序/基础设施：设置好 secret manager 后，你现在可以配置你的应用程序（通常称为 clients）从 secret manager 中查询 secret。每个 secret manager 都有自己偏好的获取 secret 的方式，例如通过 API 调用、SDK、CLI，甚至是具有严格 API 访问权限的 K8s operator。
我应该使用哪个 secret manager？
关于使用哪种 secrets management solution 的决定，在很大程度上取决于你的团队或组织的需求。例如，你可能会考虑是否要使用 Azure Key Vault 这类云服务，或者选择像 HashiCorp Vault 这样的本地开源解决方案。进一步来说，在考虑云方案时，你可能会思考静态加密（encryption-at-rest）是否足够，或者你是否需要一个提供端到端加密的解决方案。
除此之外，你可能会考虑每个 secret manager 的功能集，以及这些功能是否足以满足你的组织需求。例如，有些解决方案提供基于路径的 secret 存储，这一特性对编排最苛刻的架构很有用；有些提供跨多个环境的鸟瞰视图，让你可以轻松比较并一眼定位任何差异；还有一些可能会把 secret scanning 和 leak prevention 等功能也打包提供。最后，你可能还会考虑设置 secret manager 的成本和难度（即学习曲线）。
在提到一些基本考量之后，你应该考虑 Infisical，这个具有出色开发者体验的开源 secret management 平台。它提供名为 Infisical Cloud 的托管服务，但也有一个 self-hosted 版本，你可以在自己的基础设施上部署，并支持端到端加密。
结论
Secret sprawl 是一个全行业范围的问题，涉及无法有效管理分散在应用程序和基础设施中的 secret 所带来的挑战。这些挑战包括难以知道 secret 位于何处、无法及时快速地吊销和轮换它们，更不用说不了解每个 secret 的完整经过；其结果就是不良的 secrets hygiene。
也就是说，通过采用一个名为 secret manager 的专用工具，例如 Infisical，你可以在一个统一的位置管理你的 secret，并最终防止 secret sprawl。
