elasticsearch-authn

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Elasticsearch Authentication

Elasticsearch 身份验证

Authenticate to an Elasticsearch cluster using any supported authentication realm that is already configured. This skill covers all built-in realms, credential verification, and the full API key lifecycle.

For roles, users, role assignment, and role mappings, see the elasticsearch-authz skill.

For detailed API endpoints, see references/api-reference.md.

Deployment note: Not all realms are available on every deployment type. See Deployment Compatibility for self-managed vs. ECH vs. Serverless details.

使用已配置的任何受支持身份验证领域对Elasticsearch集群进行身份验证。本技能涵盖所有内置领域、凭据验证以及完整的API密钥生命周期。

关于角色、用户、角色分配和角色映射，请查看 elasticsearch-authz 技能。

有关详细API端点，请参阅 references/api-reference.md。

部署说明： 并非所有领域都适用于每种部署类型。有关自托管、ECH和无服务器的详细信息，请查看部署兼容性。

Critical principles

核心原则

Never ask for credentials in chat. Do not ask the user to paste passwords, API keys, tokens, or any secret into the conversation. Secrets must not appear in conversation history.
Always use environment variables. All code examples in this skill reference environment variables (e.g.
```
ELASTICSEARCH_PASSWORD
```
,
```
ELASTICSEARCH_API_KEY
```
). When a required variable is missing, instruct the user to set it in a
```
.env
```
file in the project root — never prompt for the value directly.
Prefer
.env
over terminal exports. Agents may run commands in a sandboxed shell session that does not inherit the user's terminal environment. A
```
.env
```
file in the working directory is reliable across all execution contexts. Only suggest
```
export
```
as a fallback when the user explicitly prefers it.

切勿在对话中索要凭据。不要要求用户将密码、API密钥、令牌或任何机密粘贴到对话中。机密信息不得出现在对话历史中。
始终使用环境变量。本技能中的所有代码示例均引用环境变量（如
```
ELASTICSEARCH_PASSWORD
```
、
```
ELASTICSEARCH_API_KEY
```
）。当缺少所需变量时，指导用户在项目根目录的
```
.env
```
文件中设置——切勿直接提示输入值。
优先使用
.env
而非终端导出。Agent可能在不继承用户终端环境的沙箱Shell会话中运行。工作目录中的
```
.env
```
文件在所有执行上下文中都可靠。仅当用户明确偏好时，才建议将
```
export
```
作为备选方案。

Jobs to Be Done

适用场景

Authenticate to a cluster using username and password (native realm)
Connect using an API key (bearer token)
Verify who is currently authenticated (
```
_authenticate
```
)
Choose the right authentication realm for a deployment
Create an API key with scoped privileges for automation or service access
Rotate or invalidate an existing API key
Set up service account tokens for Elastic stack components
Authenticate with PKI / mutual TLS certificate-based authentication after PKI/TLS setup
Authenticate with configured external identity providers (SAML, OIDC, LDAP, AD, Kerberos)
Grant API keys on behalf of other users

使用用户名和密码（原生领域）对集群进行身份验证
使用API密钥（承载令牌）连接
验证当前已认证的用户（
```
_authenticate
```
）
为部署选择合适的身份验证领域
创建具有范围权限的API密钥，用于自动化或服务访问
轮换或作废现有API密钥
为Elastic Stack组件设置服务账户令牌
在PKI/TLS设置完成后，使用PKI/双向TLS证书进行身份验证
使用已配置的外部身份提供商（SAML、OIDC、LDAP、AD、Kerberos）进行身份验证
代表其他用户授予API密钥

Prerequisites

前提条件

Item	Description
Elasticsearch URL	Cluster endpoint (e.g. `https://localhost:9200` or a Cloud deployment URL)
Credentials	Depends on the realm — see the methods below
Realms configured	Authentication realms and their identity backends must already be configured (realm chain, IdP, LDAP/AD, Kerberos, PKI/TLS)

If any required value is missing, instruct the user to add it to a

.env

file in the project root. Terminal exports may not be visible to agents running in a separate shell session — the

.env

file is the reliable default. Never ask the user to paste credentials into the chat — secrets must not appear in conversation history.

项	描述
Elasticsearch URL	集群端点（如 `https://localhost:9200` 或云部署URL）
凭据	取决于领域——请参阅下方的方法
领域已配置	身份验证领域及其身份后端必须已完成配置（领域链、IdP、LDAP/AD、Kerberos、PKI/TLS）

如果缺少任何必需值，指导用户将其添加到项目根目录的

.env

文件中。终端导出可能对在独立Shell会话中运行的Agent不可见——

.env

文件是可靠的默认选择。切勿要求用户将凭据粘贴到对话中——机密信息不得出现在对话历史中。

Authentication Realms

身份验证领域

Elasticsearch evaluates realms in a configured order (the realm chain). The first realm that can authenticate the request wins. Internal realms are managed by Elasticsearch; external realms delegate to enterprise identity systems.

Elasticsearch按照配置的顺序（领域链）评估领域。第一个能够验证请求的领域将生效。内部领域由Elasticsearch管理；外部领域委托给企业身份系统。

Internal realms

内部领域

Native (username and password)

原生（用户名和密码）

Users stored in a dedicated Elasticsearch index. Simplest method for interactive use. Managed via Kibana or the user management APIs (see the elasticsearch-authz skill).

bash

curl -u "${ELASTICSEARCH_USERNAME}:${ELASTICSEARCH_PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"

用户存储在专用的Elasticsearch索引中。是交互式使用的最简单方法。可通过Kibana或用户管理API进行管理（请查看elasticsearch-authz技能）。

bash

curl -u "${ELASTICSEARCH_USERNAME}:${ELASTICSEARCH_PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"

File

文件

Users defined in flat files on each cluster node (

elasticsearch-users

CLI). Always active regardless of license state, making it the fallback for disaster recovery when paid realms are disabled. Only available on self-managed deployments.

bash

curl -u "${FILE_USER}:${FILE_PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"

用户在每个集群节点的平面文件中定义（

elasticsearch-users

CLI）。无论许可证状态如何始终处于激活状态，因此当付费领域禁用时，可作为灾难恢复的备选方案。仅适用于自托管部署。

bash

curl -u "${FILE_USER}:${FILE_PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"

External realms

外部领域

LDAP

Authenticates against an external LDAP directory using username and password. Self-managed only — not available on ECH or Serverless. Typically combined with role mappings to translate LDAP groups to Elasticsearch roles.

bash

curl -u "${LDAP_USER}:${LDAP_PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"

The request is identical to native — Elasticsearch routes it to the LDAP realm via the realm chain.

使用用户名和密码对外部LDAP目录进行身份验证。仅适用于自托管——不适用于ECH或无服务器。通常与角色映射结合使用，将LDAP组转换为Elasticsearch角色。

bash

curl -u "${LDAP_USER}:${LDAP_PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"

请求与原生领域的请求相同——Elasticsearch通过领域链将其路由到LDAP领域。

Active Directory

Authenticates against an Active Directory domain. Self-managed only — not available on ECH or Serverless. Similar to LDAP but uses AD-specific defaults (user principal name,

sAMAccountName

). Typically combined with role mappings for AD group-to-role translation.

bash

curl -u "${AD_USER}:${AD_PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"

对Active Directory域进行身份验证。仅适用于自托管——不适用于ECH或无服务器。与LDAP类似，但使用AD特定的默认值（用户主体名称、

sAMAccountName

）。通常与角色映射结合使用，将AD组转换为Elasticsearch角色。

bash

curl -u "${AD_USER}:${AD_PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"

PKI (TLS client certificates)

PKI（TLS客户端证书）

Authenticates using X.509 client certificates presented during the TLS handshake. Requires a PKI realm and TLS on the HTTP layer. On ECH, PKI support is limited — check deployment settings. Not available on Serverless. Best for service-to-service communication in mutual TLS environments.

bash

curl --cert "${CLIENT_CERT}" --key "${CLIENT_KEY}" --cacert "${CA_CERT}" \
  "${ELASTICSEARCH_URL}/_security/_authenticate"

使用TLS握手期间提供的X.509客户端证书进行身份验证。需要PKI领域和HTTP层的TLS。在ECH上，PKI支持有限——请检查部署设置。不适用于无服务器。最适合双向TLS环境中的服务到服务通信。

bash

curl --cert "${CLIENT_CERT}" --key "${CLIENT_KEY}" --cacert "${CA_CERT}" \
  "${ELASTICSEARCH_URL}/_security/_authenticate"

SAML

Enables SAML 2.0 Web Browser SSO, primarily for Kibana authentication. On self-managed, configure in

elasticsearch.yml

. On ECH, configure through the Cloud deployment settings UI. On Serverless, SAML is handled at the organization level and not configurable per project. Not usable by standard REST clients — the browser-based redirect flow is handled by Kibana. Configure another realm (e.g. native or API keys) alongside SAML for programmatic API access.

启用SAML 2.0 Web浏览器单点登录，主要用于Kibana身份验证。在自托管环境中，在

elasticsearch.yml

中配置。在ECH上，通过云部署设置UI配置。在无服务器环境中，SAML在组织级别处理，无法按项目配置。标准REST客户端无法使用——基于浏览器的重定向流由Kibana处理。请同时配置另一个领域（如原生或API密钥），以便与SAML配合用于程序化API访问。

OIDC (OpenID Connect)

OIDC（OpenID Connect）

Enables OpenID Connect SSO, primarily for Kibana authentication. On self-managed, configure in

elasticsearch.yml

. On ECH, configure through the Cloud deployment settings UI. Not available on Serverless. Like SAML, it relies on browser redirects and is not suited for direct REST client use. For programmatic access alongside OIDC, use API keys or native users.

Custom applications can exchange OIDC tokens for Elasticsearch access tokens via

POST /_security/oidc/authenticate

, but this requires implementing the full OIDC redirect flow.

启用OpenID Connect单点登录，主要用于Kibana身份验证。在自托管环境中，在

elasticsearch.yml

中配置。在ECH上，通过云部署设置UI配置。不适用于无服务器。与SAML类似，它依赖浏览器重定向，不适合直接由REST客户端使用。要与OIDC配合进行程序化访问，请使用API密钥或原生用户。

自定义应用程序可通过

POST /_security/oidc/authenticate

将OIDC令牌交换为Elasticsearch访问令牌，但这需要实现完整的OIDC重定向流。

JWT (JSON Web Tokens)

JWT（JSON Web Tokens）

Accepts JWTs issued by an external identity provider as bearer tokens. On self-managed, configure in

elasticsearch.yml

. On ECH, configure through the Cloud deployment settings UI. Not available on Serverless. Supports two token types:

id_token
(default) — OpenID Connect ID tokens for user-on-behalf-of flows.
access_token
— OAuth2 client credentials for application identity flows.

bash

curl -H "Authorization: Bearer ${JWT_TOKEN}" "${ELASTICSEARCH_URL}/_security/_authenticate"

Each JWT realm handles one token type. Configure separate realms for

id_token

and

access_token

if both are needed.

接受外部身份提供商颁发的JWT作为承载令牌。在自托管环境中，在

elasticsearch.yml

中配置。在ECH上，通过云部署设置UI配置。不适用于无服务器。支持两种令牌类型：

id_token
（默认）——用于代表用户流程的OpenID Connect ID令牌。
access_token
——用于应用程序身份流程的OAuth2客户端凭据。

bash

curl -H "Authorization: Bearer ${JWT_TOKEN}" "${ELASTICSEARCH_URL}/_security/_authenticate"

每个JWT领域处理一种令牌类型。如果需要同时支持两种类型，请配置单独的领域。

Kerberos

Authenticates using Kerberos tickets via the SPNEGO mechanism. Self-managed only — not available on ECH or Serverless. Requires a working KDC infrastructure, proper DNS, and time synchronization.

bash

kinit "${KERBEROS_PRINCIPAL}"
curl --negotiate -u : "${ELASTICSEARCH_URL}/_security/_authenticate"

The

--negotiate

flag enables SPNEGO. The

-u :

is required by curl but the username is ignored — the principal from

kinit

is used. Requires curl 7.49+ with GSS-API/SPNEGO support.

通过SPNEGO机制使用Kerberos票证进行身份验证。仅适用于自托管——不适用于ECH或无服务器。需要正常运行的KDC基础设施、正确的DNS和时间同步。

bash

kinit "${KERBEROS_PRINCIPAL}"
curl --negotiate -u : "${ELASTICSEARCH_URL}/_security/_authenticate"

--negotiate

标志启用SPNEGO。

-u :

是curl必需的参数，但用户名会被忽略——使用

kinit

中的主体。需要curl 7.49+版本并支持GSS-API/SPNEGO。

API keys

API密钥

Not a realm, but a distinct authentication mechanism. Pass a Base64-encoded API key in the

Authorization

header. Preferred for programmatic and automated access.

bash

curl -H "Authorization: ApiKey ${ELASTICSEARCH_API_KEY}" "${ELASTICSEARCH_URL}/_security/_authenticate"

ELASTICSEARCH_API_KEY

is the

encoded

value (Base64 of

id:api_key

) returned when the key was created.

并非领域，而是一种独立的身份验证机制。在

Authorization

标头中传递Base64编码的API密钥。是程序化和自动化访问的首选方式。

bash

curl -H "Authorization: ApiKey ${ELASTICSEARCH_API_KEY}" "${ELASTICSEARCH_URL}/_security/_authenticate"

ELASTICSEARCH_API_KEY

是创建密钥时返回的

encoded

值（

id:api_key

的Base64编码）。

Verify authentication

验证身份验证

Always verify credentials before proceeding:

bash

curl <auth_flags> "${ELASTICSEARCH_URL}/_security/_authenticate"

Check

username

roles

, and

authentication_realm.type

to confirm identity and method:

`authentication_realm.type`	Realm
`native`	Native
`file`	File
`ldap`	LDAP
`active_directory`	Active Directory
`pki`	PKI
`saml`	SAML
`oidc`	OpenID Connect
`jwt`	JWT
`kerberos`	Kerberos

For API keys,

authentication_type

"api_key"

(not a realm type).

在继续操作前始终验证凭据：

bash

curl <auth_flags> "${ELASTICSEARCH_URL}/_security/_authenticate"

检查

username

、

roles

和

authentication_realm.type

以确认身份和方法：

`authentication_realm.type`	领域
`native`	原生
`file`	文件
`ldap`	LDAP
`active_directory`	Active Directory
`pki`	PKI
`saml`	SAML
`oidc`	OpenID Connect
`jwt`	JWT
`kerberos`	Kerberos

对于API密钥，

authentication_type

为

"api_key"

（不属于领域类型）。

Manage API Keys

管理API密钥

Create an API key

创建API密钥

bash

curl -X POST "${ELASTICSEARCH_URL}/_security/api_key" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "name": "'"${KEY_NAME}"'",
    "expiration": "30d",
    "role_descriptors": {
      "'"${ROLE_NAME}"'": {
        "cluster": [],
        "indices": [
          {
            "names": ["'"${INDEX_PATTERN}"'"],
            "privileges": ["read"]
          }
        ]
      }
    }
  }'

The response contains

id

api_key

, and

encoded

. Store

encoded

securely — it cannot be retrieved again.

Omit

role_descriptors

to inherit a snapshot of the authenticated user's current privileges.

Limitation: An API key cannot create another API key with privileges. The derived key is created with no effective access. Use
POST /_security/api_key/grant
with user credentials instead.

bash

curl -X POST "${ELASTICSEARCH_URL}/_security/api_key" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{
    "name": "'"${KEY_NAME}"'",
    "expiration": "30d",
    "role_descriptors": {
      "'"${ROLE_NAME}"'": {
        "cluster": [],
        "indices": [
          {
            "names": ["'"${INDEX_PATTERN}"'"],
            "privileges": ["read"]
          }
        ]
      }
    }
  }'

响应包含

id

、

api_key

和

encoded

。请安全存储

encoded

——无法再次检索。

省略

role_descriptors

将继承已认证用户当前权限的快照。

限制： API密钥无法创建具有权限的其他API密钥。派生密钥创建时没有有效访问权限。请改用用户凭据或
POST /_security/api_key/grant
。

Get and invalidate API keys

获取和作废API密钥

bash

curl "${ELASTICSEARCH_URL}/_security/api_key?name=${KEY_NAME}" <auth_flags>
curl -X DELETE "${ELASTICSEARCH_URL}/_security/api_key" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{"name": "'"${KEY_NAME}"'"}'

bash

curl "${ELASTICSEARCH_URL}/_security/api_key?name=${KEY_NAME}" <auth_flags>
curl -X DELETE "${ELASTICSEARCH_URL}/_security/api_key" \
  <auth_flags> \
  -H "Content-Type: application/json" \
  -d '{"name": "'"${KEY_NAME}"'"}'

Examples

示例

Create a scoped API key

创建范围受限的API密钥

Request: "Create an API key that can only read from

metrics-*

json

POST /_security/api_key
{
  "name": "metrics-reader-key",
  "expiration": "90d",
  "role_descriptors": {
    "metrics-reader": {
      "indices": [
        {
          "names": ["metrics-*"],
          "privileges": ["read", "view_index_metadata"]
        }
      ]
    }
  }
}

请求： "创建一个只能从

metrics-*

读取数据的API密钥。"

json

POST /_security/api_key
{
  "name": "metrics-reader-key",
  "expiration": "90d",
  "role_descriptors": {
    "metrics-reader": {
      "indices": [
        {
          "names": ["metrics-*"],
          "privileges": ["read", "view_index_metadata"]
        }
      ]
    }
  }
}

Verify which realm authenticated the user

验证哪个领域对用户进行了身份验证

json

GET /_security/_authenticate

json

{
  "username": "joe",
  "authentication_realm": { "name": "ldap1", "type": "ldap" },
  "authentication_type": "realm"
}

json

GET /_security/_authenticate

json

{
  "username": "joe",
  "authentication_realm": { "name": "ldap1", "type": "ldap" },
  "authentication_type": "realm"
}

Authenticate with a JWT bearer token

使用JWT承载令牌进行身份验证

bash

curl -H "Authorization: Bearer ${JWT_TOKEN}" "https://my-cluster:9200/_security/_authenticate"

Confirm the response shows

authentication_realm.type

"jwt"

bash

curl -H "Authorization: Bearer ${JWT_TOKEN}" "https://my-cluster:9200/_security/_authenticate"

确认响应中

authentication_realm.type

为

"jwt"

。

Guidelines

指南

Choosing an authentication method

选择身份验证方法

Method	Best for	Trade-offs
Native user	Interactive use, simple setups	Password must be stored or prompted
File user	Disaster recovery, bootstrap	Must be configured on every node
API key	Programmatic access, CI/CD, scoped access	Cannot be retrieved after creation
LDAP / AD	Enterprise directory integration	Requires network access to directory server
PKI certificate	Service-to-service, mutual TLS environments	Requires PKI infrastructure and PKI realm
SAML	Kibana SSO via enterprise IdP	Browser-only; not for REST clients
OIDC	Kibana SSO via OpenID Connect provider	Browser-only; not for REST clients
JWT	Token-based service and user authentication	Requires external token issuer and realm config
Kerberos	Windows/enterprise Kerberos environments	Requires KDC, DNS, time sync infrastructure

Prefer API keys for automated workflows — they support fine-grained scoping and independent expiration. For Kibana SSO, use SAML or OIDC. For enterprise directory integration, use LDAP or AD with role mappings (see elasticsearch-authz).

方法	最佳适用场景	权衡因素
原生用户	交互式使用、简单设置	密码必须存储或提示输入
文件用户	灾难恢复、引导配置	必须在每个节点上配置
API密钥	程序化访问、CI/CD、范围受限访问	创建后无法再次检索
LDAP / AD	企业目录集成	需要与目录服务器的网络访问权限
PKI证书	服务到服务、双向TLS环境	需要PKI基础设施和PKI领域
SAML	通过企业IdP实现Kibana单点登录	仅支持浏览器；不适用于REST客户端
OIDC	通过OpenID Connect提供商实现Kibana单点登录	仅支持浏览器；不适用于REST客户端
JWT	基于令牌的服务和用户身份验证	需要外部令牌颁发者和领域配置
Kerberos	Windows/企业Kerberos环境	需要KDC、DNS、时间同步基础设施

对于自动化工作流，优先使用API密钥——它们支持细粒度范围划分和独立过期。对于Kibana单点登录，使用SAML或OIDC。对于企业目录集成，使用LDAP或AD并结合角色映射（请查看elasticsearch-authz）。

Avoid superuser credentials

避免使用超级用户凭据

Never use the built-in

elastic

superuser or any

superuser

-role account for day-to-day operations, automation, or application access. Instead, create a dedicated user or API key with only the privileges the task requires. The

elastic

user should be reserved for initial cluster setup and emergency recovery only.

切勿使用内置的

elastic

超级用户或任何拥有

superuser

角色的账户进行日常操作、自动化或应用程序访问。相反，创建仅拥有任务所需权限的专用用户或API密钥。

elastic

用户应仅保留用于初始集群设置和紧急恢复。

Security

安全注意事项

An API key cannot create another API key with privileges. Use user credentials or
```
POST /_security/api_key/grant
```
for programmatic key creation.
Always set
```
expiration
```
on API keys. Avoid indefinite keys in production.
Scope API keys via
```
role_descriptors
```
. Never create unscoped keys for automated systems.
Never receive, echo, or log passwords, API keys, tokens, or any credentials in the chat. Instruct the user to manage secrets in their terminal, environment variables, or files directly.
Never store secrets in code, scripts, or version control. Load from environment variables.
Use
```
GET /_security/_authenticate
```
to verify credentials before running management operations.
When generating passwords for native users, use at least 16 characters mixing uppercase, lowercase, digits, and symbols. Never use placeholder values like
```
changeme
```
or
```
password123
```
.
SAML and OIDC are for browser-based SSO only. Always configure a companion realm (native, file, or API keys) for REST API access alongside them.

API密钥无法创建具有权限的其他API密钥。使用用户凭据或
```
POST /_security/api_key/grant
```
进行程序化密钥创建。
始终为API密钥设置
```
expiration
```
。在生产环境中避免使用无限期密钥。
通过
```
role_descriptors
```
为API密钥设置范围。切勿为自动化系统创建无范围限制的密钥。
切勿在对话中接收、回显或记录密码、API密钥、令牌或任何凭据。指导用户直接在终端、环境变量或文件中管理机密。
切勿将机密存储在代码、脚本或版本控制中。从环境变量加载。
在运行管理操作前，使用
```
GET /_security/_authenticate
```
验证凭据。
为原生用户生成密码时，使用至少16个字符，混合大小写字母、数字和符号。切勿使用
```
changeme
```
或
```
password123
```
这类占位符值。
SAML和OIDC仅适用于基于浏览器的单点登录。请始终配置配套领域（原生、文件或API密钥），以便与它们配合用于REST API访问。

Deployment Compatibility

部署兼容性

Not all authentication realms are available on every deployment type. Self-managed clusters support all realms. Elastic Cloud Hosted (ECH) is managed by Elastic with no node-level access. Serverless is fully managed SaaS.

Realm	Self-managed	ECH	Serverless
Native	Yes	Yes	Not available
File	Yes	Not available	Not available
LDAP	Yes	Not available	Not available
Active Directory	Yes	Not available	Not available
PKI	Yes	Limited	Not available
SAML	Yes	Yes (deployment config)	Organization-level
OIDC	Yes	Yes (deployment config)	Not available
JWT	Yes	Yes (deployment config)	Not available
Kerberos	Yes	Not available	Not available
API keys	Yes	Yes	Yes

ECH notes:

No node access, so the file realm and
```
elasticsearch-users
```
CLI are not available.
LDAP, Active Directory, and Kerberos cannot be configured on ECH.
SAML, OIDC, and JWT are configurable via the Cloud deployment settings UI.
The
```
elastic
```
superuser is available but should still be avoided for routine use.

Serverless notes:

API keys are the primary authentication method.
Native users do not exist — users are managed at the Elastic Cloud organization level.
SAML SSO is configured at the organization level, not per project.

并非所有身份验证领域都适用于每种部署类型。自托管集群支持所有领域。**Elastic Cloud托管（ECH）**由Elastic管理，无节点级访问权限。无服务器是完全托管的SaaS。

领域	自托管	ECH	无服务器
原生	是	是	不可用
文件	是	不可用	不可用
LDAP	是	不可用	不可用
Active Directory	是	不可用	不可用
PKI	是	受限	不可用
SAML	是	是（部署配置）	组织级
OIDC	是	是（部署配置）	不可用
JWT	是	是（部署配置）	不可用
Kerberos	是	不可用	不可用
API密钥	是	是	是

ECH注意事项：

无节点访问权限，因此文件领域和
```
elasticsearch-users
```
CLI不可用。
无法在ECH上配置LDAP、Active Directory和Kerberos。
SAML、OIDC和JWT可通过云部署设置UI配置。
```
elastic
```
超级用户可用，但仍应避免用于常规操作。

无服务器注意事项：

API密钥是主要的身份验证方法。
不存在原生用户——用户在Elastic Cloud组织级别管理。
SAML单点登录在组织级别配置，而非按项目配置。