作者：来自 Elastic Alex Chalkias
了解 Elastic 如何通过全球分布式 IAM 架构，在 Serverless 中统一控制平面和数据平面的身份验证。使用一个 API key 同时访问 Cloud 和 Elasticsearch API。
通过 Elastic Cloud Serverless 摆脱运维负担。自动扩展、应对流量峰值，并专注于构建 —— 立即开始 14 天免费试用亲自体验！
你可以参考这些指南来构建 AI 驱动的搜索体验，或在各类业务系统和软件之间进行搜索。
想象一下，你是一名站点可靠性工程师（SRE），负责不断增长的一组 Elastic Cloud Serverless 项目：用于生产基础设施的 Elastic Observability、用于安全运营中心（SOC）团队的 Elastic Security，以及用于面向客户应用的 Elasticsearch。每个项目都有各自的 Elasticsearch API key。你的持续集成与持续交付（CI/CD）流水线需要一个单独的 Cloud API key 来配置和管理这些项目。每个季度的密钥轮换日到来时：你需要逐个项目生成新密钥、更新 Terraform 状态、重新部署流水线，并祈祷没有遗漏。当凌晨 2 点发生故障并需要快速撤销访问权限时，你还要对照一张凭证表来确认哪个 key 属于哪个项目和服务。
如今，这一切变得简单多了。Elastic Cloud API key 现在可以直接用于对 Elastic Cloud Serverless 上的 Elasticsearch 和 Kibana API 进行身份验证。你现在可以使用一个凭证来管理组织资源并执行数据操作，例如 Elasticsearch Query Language（ES|QL）查询、数据摄取和告警。
接下来我们将看看我们为什么构建这个功能、如何通过全球分布式身份层来实现它，以及它如何为跨项目搜索奠定基础。
密钥管理负担（The secret management burden）
围绕数据平台构建可靠的 CI/CD 流水线、GitOps 工作流或 Terraform 自动化会带来一个隐藏成本：密钥泛滥（secret sprawl）。
在之前的模型中，开发者面临的是一个割裂的认证体系：
- 控制平面（Elastic Cloud API key）：组织级别的 key，用于通过 Elastic Cloud API 创建项目、邀请用户以及管理计费。
- 数据平面（Elasticsearch API key）：项目级别的 key，在特定的 Serverless 项目中创建，用于与 Elasticsearch 和 Kibana API 交互。
这意味着你的部署脚本必须先对 Elastic Cloud 进行身份验证，创建一个 Serverless 项目，从该项目中提取一个新生成的 Elasticsearch API key，然后再将这个第二个 key 注入到下游应用或自动化工具中，从而导致流水线复杂、审计日志分散，并增加凭证泄露的风险。
Elastic Cloud Serverless 中的统一认证（Unified authentication in Elastic Cloud Serverless）
在此次发布中，对于 Serverless 项目，这种分裂已经消失。你现在可以创建一个明确授权用于 Cloud、Elasticsearch 和 Kibana API 的 Elastic Cloud API key。
- 之前：Elastic Cloud API key 严格来说只是控制平面的令牌。它可以创建项目、管理计费和邀请用户，但存在一个明确边界；它无法用于调用这些项目内部的 Elasticsearch 或 Kibana API。你始终需要第二个、特定于项目的 key 来执行数据操作。
- 现在：在创建 Elastic Cloud API key 时选择启用 Cloud、Elasticsearch 和 Kibana API 访问后，这一硬性边界在 Serverless 中被移除。该 API key 成为一个真正统一的凭证。它在保留管理组织基础设施能力的同时，也获得了对任意已授权 Serverless 项目的原生访问能力，可用于查询、摄取和分析数据。
通过将这些能力统一到一个 Elastic Cloud API key 下，你获得了一个可以统一进行范围控制、审计、轮换和撤销的身份。每一次 API 调用，无论是创建新项目还是执行 ES|QL 查询，都会在审计日志中以同一个凭证出现，从而在故障调查或合规审查时提供一条清晰的追踪路径。凭证轮换也从需要协调控制平面和数据平面多个密钥的复杂流程，简化为一步操作。此外，由于角色分配是按项目进行的，一个 key 可以跨多个项目使用，例如在 observability 项目中管理数据摄取，同时在 security 项目中运行查询，而无需为每个项目维护不同的凭证。
需要强调的是，“统一”并不意味着“全能”。通过使用 role_assignments 负载，你可以将统一 key 严格限定在单个项目和特定角色（例如只读），从而在凭证泄露时将影响范围完全控制住。如果某个开发者离开或某个应用被下线，你可以在 Elastic Cloud Console 中撤销一个 key，即可立即终止其在控制平面以及所有相关 Elasticsearch 项目中的访问权限。
（注意：对于 Elastic Cloud Hosted/托管部署，Cloud API key 目前仍仅用于管理控制平面。将其扩展到托管集群 API 的支持计划在未来版本中推出。）
自动化你的工作流程（Automating your workflows）
上手非常简单。你可以完全通过 Elastic Cloud 控制台进行配置，或者使用 Elastic Cloud API 实现自动化。
UI 操作流程保持不变，但现在你可以在项目角色分配中选择 Cloud、Elasticsearch 和 Kibana API 访问权限。
下面是如何使用 Elastic Cloud API 以编程方式创建统一 key。请注意 application_roles 数组，因为它赋予该 key 对 Elasticsearch 数据平面的原生访问权限：
`
1. curl -X POST \
2. -H "Content-Type: application/json" \
3. -H "Authorization: ApiKey $EC_API_KEY" \
4. "https://api.elastic-cloud.com/api/v1/users/auth/keys" \
5. -d '{
6. "description": "unified-automation-key",
7. "expiration": "90d",
8. "role_assignments": {
9. "project": {
10. "elasticsearch": [
11. {
12. "role_id": "elasticsearch-admin",
13. "organization_id": "YOUR_ORG_ID",
14. "all": false,
15. "project_ids": ["YOUR_PROJECT_ID"],
16. "application_roles": ["admin"]
17. }
18. ]
19. }
20. }
21. }'
`AI写代码
创建完成后，你只需将这个相同的 key 放在 Authorization: ApiKey 头中，同时用于 api.elastic-cloud.com 和你对应的 Serverless Elasticsearch 端点。
底层实现：构建分布式身份层
让一个 Cloud API key 同时在控制平面和数据平面工作，并不是简单地传递一个 token 就能实现的。这需要解决一个基础的分布式系统问题。
历史上，Cloud API key 存储在一个集中式的全局安全集群中。这对于控制平面操作来说是可行的，因为这类操作可以接受较高的延迟。然而，Elasticsearch 的数据请求需要极低延迟。我们无法承受每一次搜索查询或数据摄取请求都跨越全球访问中央控制平面进行校验。
为了解决这一问题，我们引入了一种新的认证架构，由一个全球分布式的数据存储提供支持。下面的时序图展示了客户端使用 Elastic Cloud API key 发送 Elasticsearch 查询的过程，说明认证是如何完全在本地区域内完成的，而无需往返全局控制平面。Elasticsearch 将认证委托给区域 IAM 服务，该服务会在本地副本中验证 key 并解析其角色分配（这些副本来自全球分布式数据库）。一旦授权完成，Elasticsearch 执行查询并将结果返回给客户端。
全球分布式持久化
不再仅依赖集中式安全集群，Elastic Cloud API key 及其相关的角色定义现在被持久化在一个全球分布式、高可用的数据库中。该数据库在全球控制平面和实际运行 Serverless 项目的各区域数据平面之间同步身份与访问管理（IAM）数据。
基于区域 IAM 的本地校验
当客户端使用 Elastic Cloud API key 向 Elasticsearch 发送请求时，请求不会回到全局控制平面，而是被路由到新的区域 IAM 服务。该服务会在本地数据库副本中验证 key，从而确保认证以接近零延迟完成，并且完全不受全局控制平面故障的影响。
动态角色映射
认证只是问题的一半，系统还需要对请求进行授权。区域 IAM 服务会即时将 Cloud 层级的角色分配（例如 application_roles）转换为原生的 Elasticsearch 权限。随后 Elasticsearch 可以在本地完成授权并执行请求，而无需依赖本地的 .security 索引。
跨项目搜索的基础
这种分布式身份架构为 Elastic 平台的未来奠定了基础。
由于身份和访问现在是统一且全局同步的，我们具备了在不同项目之间安全传递身份的能力。这为即将推出的 Serverless 跨项目搜索（Cross-Project Search，CPS）功能提供了基础。
通过 CPS，你将能够像操作单一数据集一样，查询跨多个远程 Serverless 项目的数据，例如将安全和可观测性工作负载结合在一起。借助统一的 API key，系统可以自动在所有项目中评估你的权限，而无需你在每个目标项目上配置复杂的信任关系、证书或重复的凭证。
了解更多
准备好简化你的技术栈了吗？
- 阅读 Elastic Cloud API key 文档，了解如何分配 stack 访问权限。
- 查看 Create API key（Elastic Cloud API）参考文档，以自动化生成 key。
- 查阅 Elastic API key 文档，了解 Elastic 平台中不同 key 类型的完整对比。
立即开始或继续在 Elastic Cloud 上构建。
免责声明（Disclaimer）
本文中描述的任何功能或特性的发布及时间安排完全由 Elastic 自行决定。任何当前尚不可用的功能或特性，可能无法按时交付，甚至可能不会交付。
