什么是 Secret Zero 问题？云原生密钥管理深度解析

理解 Secret Zero 问题

云计算的兴起从根本上改变了安全性的实现方式。组织不再能够依赖“堡垒”模型——即将一切都保护在安全的内部网络或“边界”之后。现代软件系统分布在互联网上，需要可靠的方法来识别和认证各个部分，以确保它们能够安全地相互信任并进行通信。这涉及三个相互关联的要素：

• 证明身份通常需要提供一个 secret 凭证
• 大规模管理 secrets 需要有效的访问控制来保护和分发敏感信息
• 实现访问控制依赖于建立 identity，以验证是谁或什么在请求访问

这种循环依赖——secrets、访问控制和 identity 彼此相互依赖——使得解决安全难题变得尤为复杂。

在这篇博文中，我们将探讨“secret zero”问题——它是什么、为什么重要，以及像 Infisical 这样的现代解决方案如何有效应对这一基础性的安全悖论。

理解 Secret Zero 问题

“secret zero”问题本质上是一个先有鸡还是先有蛋的困境：当你需要一个 secret 才能访问 secrets 时，如何安全地访问这些 secrets？正如引言中提到的，在云原生应用和基础设施中，这个问题尤其重要，因为系统会通过互联网这类不安全的通道进行通信。

考虑一个常见场景：你的应用需要数据库凭证才能运行。这些凭证不能硬编码，因为这会带来巨大的安全风险（你的源代码可能泄露，或被未授权的行为者访问）。于是你决定将它们存储在一个 secrets manager 中，比如 Infisical。但你如何安全地获取那个用于解锁其他所有应用 secrets 的第一个 secret 呢？

有人建议使用诸如 SOPS 之类的工具对配置文件（更具体地说，是其中的值）进行加密。然而，这只是把问题往后推了一步：你如何安全地分发 SOPS 所需的加密密钥？这就像那句老话说的：“一切都要追溯到乌龟！”——保护一个 secret 需要保护另一个 secret，而这又需要保护下一个 secret，如此循环往复。

从问“你知道什么？”到“你是谁？”

要解决认证问题，我们需要将重点从通过 secrets 证明可信性，转移到证明 identity 本身。关键的变化是从“你拥有什么？”转向“你是谁？”这就是为什么 identity 处于现代认证的核心。

如今的 identity 系统已经超越了简单的共享 secret：它们通过多个可信来源验证 identity，从而形成一个比仅验证已存储信息更全面的验证流程。

这与我们在现实中验证身份的方式类似——我们不会只询问密码，而是会检查政府签发的 ID、身体特征以及上下文细节。我们可以将这种多维度的方法应用于机器认证，借助可信 identity provider、硬件安全模块和 cryptographic attestation 来实现。

从基于 secret的认证转向基于 identity的认证，为现代应用建立了更稳固的基础。通过专注于建立和验证 identities，而不是管理共享 secrets，我们就可以摆脱 secret zero 悖论。

识别人类和机器

Identity 验证大致分为两类：人和机器。

对于人，Single Sign-On (SSO) 和 federated identity provider 已成为解决 secret zero 问题的有效方案，同时也解决了更常见的弱密码和密码重复使用问题。

当用户通过 SSO 进行认证时，他们会通过 Google、GitHub 或企业目录等可信 provider 来证明自己的 identity。随后，这些 provider 会通过安全的 token exchange 为用户背书。这种认证委托简化了诸如多因素认证（MFA）和全面访问日志记录等关键安全功能的实现。

SSO 通过借助 cryptographic protocols 和 identity federation 建立信任，有效解决了人类用户的 secret zero 问题。那么机器呢？

Machine Identities

Machine identity 与人类 identity 相比面临着独特的挑战，因为它覆盖的范围更广，也更加抽象。Machine 可以是笔记本电脑这样的物理设备、虚拟机、容器、应用程序、REST API，或任何一段代码。更复杂的是，这些实体通常会被快速创建和释放，尤其是在现代基础设施中，资源往往是短暂且弹性的。在容器化环境中，实例可能只存在几分钟或几小时就会被替换。传统的 machine 认证方法依赖长期存在的凭证或静态 IP 地址，难以跟上这种动态环境的节奏。

挑战不仅在于识别 machines——还在于如何以安全且可扩展的方式做到这一点。我们需要一个解决方案，既能应对云基础设施的动态特性，又能保持强大的安全保证，并避免 secret zero 问题。

Infisical 如何解决 Secret Zero 问题

这正是像 Infisical 这样的 machine identity 方法大放异彩的地方。其概念很直接：利用你现有的基础设施来委托 machines 的认证。这种方法之所以强大，是因为它让你能够以更简单、更安全的方式，利用自己偏好的平台来引导初始 secret。

让我们回到最初的例子：部署一个需要数据库凭证的应用。假设该应用将在云环境中运行。思路是利用云 provider 内置的 identity 机制来获取一个短期有效的 access token，然后应用再使用这个 token 从 Infisical 中检索存储的数据库凭证。这可以通过以下任一cloud-native authentication method来实现：

• AWS Auth with IAM roles
• Azure Auth with Azure AD
• GCP Auth with Google Cloud Platform service accounts

更进一步，你还可以使用与平台无关的 OIDC Auth 方法。这意味着，任何实现了 OpenID Connect 协议的平台或环境，都可以作为你的可信 identity provider。像 GitHub、GitLab 和 CircleCI 这样的流行 CI 工具都支持该协议，因此它们可以直接与 Infisical 配合使用，从而在持续集成期间安全地访问 build secrets。

另一个常见用例是在 Kubernetes 集群中的 pod 里运行应用。Kubernetes Auth 是一种 Kubernetes 原生的认证方法，使 Infisical 能够直接针对 Kubernetes API 验证应用的 identity。这对于非托管的 K8s 环境尤其有价值，因为像 Amazon Elastic Kubernetes Service (EKS) 这样的托管服务，如前所述，已经可以利用它们的 identity management systems。

对于需要更直接方法的场景，Infisical 还提供了另外两种 machine 认证方法：

• Universal Auth : 这种与平台无关的认证方法可以为 machine identity 进行配置，使其能够使用 Client ID 和 Client Secret 从任意平台或环境进行认证。客户端会获得一个短期有效的 access token，用于向 Infisical API 发起经过认证的请求。虽然这种方法是基于 identity 的，但 Client ID/Secret 对是敏感信息，应该谨慎处理，绝不要将其嵌入 source code。
• Token Auth : 与其他认证方法不同，其他方法通常让客户端交换凭证以换取短期有效的 access token，而 Token Auth 允许使用一个 token 直接向 Infisical API 发起经过认证的请求。它的工作方式类似于 API Key；虽然使用起来很直接，但安全的 token 管理至关重要。

这些认证方法构成了一个全面的工具集，用于应对 secret zero 问题，每一种都针对不同的部署场景提供了独特优势。虽然 cloud-native 解决方案利用现有基础设施来实现最大的安全性，但像 Universal Auth 这样的方式则在灵活性和控制之间取得了平衡。

Infisical 持续扩展其认证方法，以增强在不同用例中的灵活性和集成能力（另一个值得注意的 machine authentication method 是 LDAP）。

这种多样性确保组织能够根据其特定的安全需求和基础设施限制，实施最合适的认证策略。

总结

“secret zero”问题起初看起来像一个不可能的悖论：两个系统如何在不共享初始 secret 的情况下建立信任？然而，换个角度来表述这个问题，就有助于解决它。与其问“我们应该把第一个 secret 存在哪里？”，不如问“我们真的需要 secret 吗？”

事实证明，要让不受信任网络上的机器到机器通信变得安全，并不需要直接共享敏感凭证。相反，一种更优雅的方法是让机器通过利用现有基础设施来证明自己的 identity。这一策略可以防止“secrets sprawl”——即凭证在系统之间失控扩散——并使攻击者更难通过窃取凭证来危害你的基础设施。

Infisical 的基于 identity 的认证方法帮助开发者构建安全、可扩展的应用，而无需直接管理敏感凭证。这主要围绕四个支柱展开：

1. 利用现有 identity provider： Infisical 集成了 cloud provider IAM roles、Kubernetes service accounts 和 OIDC，以利用现有可信 identity 基础设施，消除对额外长期 secret 的需求。
2. 短期有效的 Access Token： 认证后，Infisical 会发放短期有效的 access token 用于访问 secrets，从而限制潜在泄露的影响。
3. 最小化凭证： 对于需要更多灵活性的用例，Infisical 提供了 Universal Auth 方法，将问题简化为管理一对 client ID/Secret。这些凭证可以通过许多 orchestration 平台和部署流水线注入的环境变量来安全获取。
4. 自动续期： Infisical Agent、SDKs 和部分集成会自动续期 access token，确保 secrets 持续可用而无需人工干预。

无论你是在云端、Kubernetes 还是本地环境中部署，Infisical 都提供了满足你 secret 管理需求的工具和灵活性。

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