为 Elastic Cloud Serverless 和 Elasticsearch 引入统一的 API 密钥。

假设您是一名站点可靠性工程师 (SRE)，负责管理不断增长的 Elastic Cloud Serverless 项目组合：用于生产基础架构的 Elastic Observability、用于安全运营中心 (SOC) 团队的 Elastic Security，以及用于面向客户应用程序的 Elasticsearch。每个项目都有自己专用的 Elasticsearch API 密钥。您的持续集成和持续交付（CI/CD）管道需要单独一个 Cloud API 密钥来配置和管理这些项目。每季度一次的密钥轮换日到来时：您需要逐个检查每个项目，生成新密钥，更新 Terraform 状态，重新部署管道，并希望一切不出纰漏。当凌晨 2 点发生故障，需要快速撤销访问权限时，您不得不对照一份电子表格来确认哪个密钥属于哪个项目、哪个服务。

如今，这一切变得简单得多。Elastic Cloud API 密钥现在可以直接在 Elastic Cloud Serverless 上对 Elasticsearch 和 Kibana API 进行身份验证。您现在可以使用单一凭证来管理组织的资源并执行数据操作，例如 Elasticsearch 查询语言 (ES|QL) 查询、数据摄取和告警。

下面我们来看看我们构建这一功能的原因、如何设计全局分布式身份层来实现这一目标，以及它如何为跨项目搜索奠定基础。

秘密管理负担

围绕数据平台构建可靠的 CI/CD 管道、GitOps 工作流或 Terraform 自动化，都伴随着一项隐性成本：秘密信息蔓延。

在旧模式下，开发人员面临割裂的身份验证体验：

• 控制平面 (Elastic Cloud API 密钥)：组织级密钥，组织级作用域的密钥，用于通过 Elastic Cloud API 创建项目、邀请用户和管理计费。
• 数据平面（Elasticsearch API 密钥）： 项目范围密钥是在特定的 Serverless 项目中创建的，用于与 Elasticsearch 和 Kibana API 进行交互。

这意味着您的部署脚本必须对 Elastic Cloud 进行身份验证，配置 Serverless 项目，从该特定项目中提取新生成的 Elasticsearch API 密钥，然后将该密钥注入下游应用程序或自动化工具，从而导致复杂的管道、分散的审计日志以及更高的凭证泄露风险。

Elastic Cloud Serverless 中的统一身份验证

通过此次发布，Serverless 项目的拆分问题将不复存在。您现在可以创建一个明确授权用于 云、Elasticsearch 和 Kibana API 的 Elastic Cloud API 密钥。

• 以前：Elastic Cloud API 密钥严格来说是控制平面令牌。它可以创建项目、管理计费和邀请用户，但存在一个硬边界：它不能用于调用这些项目内部的 Elasticsearch 或 Kibana API。您始终需要第二个特定于项目的密钥来执行数据操作。
• 现在： 在创建 Elastic Cloud API 密钥时，选择 Cloud、Elasticsearch 和 Kibana API 访问权限，Serverless 的硬边界就被移除了。该 API 密钥成为一个真正统一的凭证。它保留了管理组织基础架构的能力，同时获得了跨任何已授权 Serverless 项目进行查询、摄取和分析数据的原生访问能力。

通过将这一切统一到单个 Elastic Cloud API 密钥之下，您获得了一个统一的身份，可以作为一个整体进行范围限定、审计、轮换和撤销。每个 API 调用——无论是配置新项目还是运行 ES|QL 查询——都会在审计日志中显示为使用同一凭证，从而在事件调查或合规性审查期间为您提供单一的追踪线索。凭证轮换成为一步操作，而无需跨独立的控制平面和数据平面秘密信息进行协调更新。而且由于角色分配是按项目进行的，一个密钥可以跨多个项目使用——在您的可观测项目中管理数据摄取，在安全项目中运行查询——无需为每个项目分别管理不同的凭证。

重要的是，统一并不意味着全部权限。通过使用 role_assignments 有效负载，您可以将统一密钥严格限定到单个项目和特定角色（例如只读），从而确保即使凭证泄露，其影响范围也能得到完全控制。如果某位开发人员离职或某个应用程序被停用，您可以在 Elastic Cloud Console 中撤销单个密钥，立即终止对控制平面以及所有关联 Elasticsearch 项目的访问。

(注意：对于 Elastic Cloud Hosted / 托管部署，Cloud API 密钥仍仅用于控制平面管理。计划在未来的版本中支持将其扩展到托管堆栈 API。）

自动化您的工作流

入门很简单。您可以完全通过 Elastic Cloud 控制台进行配置，也可以使用 Elastic Cloud API 对其进行自动配置。

UI 流程保持不变，但现在您可以在项目角色分配下选择 Cloud、Elasticsearch 和 Kibana API 访问权限。

下面说明如何使用 Elastic Cloud API 以编程方式创建统一密钥。请注意 application_roles 数组，正是它授予了密钥对 Elasticsearch 数据平面的原生访问权限：

一旦创建，您只需在 Authorization: ApiKey 标头中向 api.elastic-cloud.com 以及您的特定 Serverless Elasticsearch 终端传递完全相同的这个密钥即可。

底层实现：构建分布式身份层

使一个 Cloud API 密钥能够在控制平面和数据平面同时工作，并不像传递一个令牌那么简单。这需要解决一个根本性的分布式系统挑战。

过去，Cloud API 密钥存储在一个中心化的全局安全集群中。这对于可以接受较高延迟的控制平面操作来说没有问题。然而，Elasticsearch 数据请求要求超低延迟。我们不能为了验证每个搜索查询或摄取请求而在全局范围内往返访问中央控制平面。

为了解决这个问题，我们引入了一种由全局分布式数据存储提供支持的新身份验证架构。下面的序列图展示了一个客户端使用 Elastic Cloud API 密钥发送 Elasticsearch 查询的过程，说明了身份验证完全在本地区域内完成，无需往返全局控制平面。Elasticsearch 将身份验证委托给区域 IAM 服务，该服务针对全局分布式数据库的本地副本验证密钥并解析其角色分配。一旦授权通过，Elasticsearch 执行查询并将结果返回给客户端。

全局分布式持久化

Elastic Cloud API 密钥及其关联的角色定义不再仅依赖集中式安全集群，而是持久化存储在全球分布的高可用数据库中。该数据库在全球控制平面与实际运行您的 Serverless 项目的区域数据平面之间同步身份与访问管理 (IAM) 数据。

使用区域 IAM 进行本地验证

当您的客户端使用 Elastic Cloud API 密钥向 Elasticsearch 发送请求时，该请求不会返回全局控制平面。相反，它会被路由到新的区域 IAM 服务。它会验证本地数据库副本中的密钥，确保身份验证几乎无延迟，并且完全不受全局控制平面故障的影响。

动态角色映射

身份验证只是成功的一半；系统还需要对请求进行授权。区域 IAM 服务可立即将您的云端角色分配 (例如 application_roles) 转换为原生 Elasticsearch 权限。Elasticsearch 随后可在本地授权并执行请求，完全无需本地 .security 索引。

跨项目搜索的基础

这种分布式身份架构是 Elastic 平台未来发展的基础构建块。

由于身份和访问权限现在统一且全局同步，我们拥有了在不同项目之间安全传递您身份所需的框架。这为 Serverless 即将推出的 跨项目搜索 (CPS) 功能提供了支持。

借助 CPS，您将能够查询跨越多个远程 Serverless 项目的数据，例如将安全负载和可观测负载组合起来，就像它们是单一数据集一样简单。通过依赖统一 API 密钥，系统可以自动评估您在所有项目上的权限，而无需您在每个目标项目上配置复杂的信任关系、证书或重复的凭证。

了解详情

准备好简化您的技术栈了吗？

• 请参阅 Elastic Cloud API 密钥文档，了解如何分配堆栈访问权限。
• 请参考 Create API key（Elastic Cloud API） 文档，以实现密钥自动生成。
• 查看 Elastic API 密钥，了解 Elastic 平台中各类密钥的完整对比。

立即开始在 Elastic Cloud 上构建或继续您的构建之旅。

免责声明

本文中描述的任何功能或功能性的发布和时间均由 Elastic 自行决定。当前尚未发布的任何功能或功能性可能无法按时提供或根本无法提供。