Authenticate to an Elasticsearch cluster using any supported authentication realm that is already configured. This skill
Works with
covers all built-in realms, credential verification, and the full API key lifecycle.
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versionelasticsearch-authnExecute the skills CLI command in your project's root directory to begin installation:
Fetches elasticsearch-authn from elastic/agent-skills and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate elasticsearch-authn. Access via /elasticsearch-authn in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Create detailed user stories, acceptance criteria, and feature specs
Example
Generate user stories for 'password reset feature' with acceptance criteria, edge cases, and test scenarios
Reduce spec writing time by 50%, ensure comprehensive coverage
Research competitors, compare features, identify gaps
Example
Analyze 5 competitor products, create feature comparison matrix, suggest differentiation opportunities
Complete competitive research in 2 hours instead of 2 days
Evaluate features using frameworks (RICE, ICE, Kano) and create prioritized backlogs
Example
Score 20 feature ideas using RICE framework, generate prioritized roadmap with rationale
0
total installs
0
this week
296
GitHub stars
0
upvotes
Run in your terminal
0
installs
0
this week
296
stars
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_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..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._authenticate)| 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 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.
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).
curl -u "${ELASTICSEARCH_USERNAME}:${ELASTICSEARCH_PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"
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.
curl -u "${FILE_USER}:${FILE_PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"
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.
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.
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.
curl -u "${AD_USER}:${AD_PASSWORD}" "${ELASTICSEARCH_URL}/_security/_authenticate"
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.
curl --cert "${CLIENT_CERT}" --key "${CLIENT_KEY}" --cacert "${CA_CERT}" \
"${ELASTICSEARCH_URL}/_security/_authenticate"
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.
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.
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.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.
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.
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.
Not a realm, but a distinct authentication mechanism. Pass a Base64-encoded API key in the Authorization header.
Preferred for programmatic and automated access.
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.
Always verify credentials before proceeding:
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 is "api_key" (not a realm type).
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/grantwith user credentials instead.
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}"'"}'
Request: "Create an API key that can only read from metrics-*."
POST /_security/api_key
{
"name": "metrics-reader-key",
"expiration": "90d",
"role_descriptors": {
"metrics-reader": {
"indices": [
{
"names": ["metrics-*"],
"privileges": ["read", "view_index_metadata"]
}
]
}
}
}
GET /_security/_authenticate
{
"username": "joe",
"authentication_realm": { "name": "ldap1", "type": "ldap" },
"authentication_type": "realm"
}
curl -H "Authorization: Bearer ${JWT_TOKEN}" "https://my-cluster:9200/_security/_authenticate"
Confirm the response shows authentication_realm.type as "jwt".
| 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-au
Make data-driven prioritization decisions faster
Draft PRDs, status updates, and stakeholder presentations
Example
Create executive summary of Q3 roadmap, monthly progress report, feature launch announcement
Save 3-5 hours/week on communication overhead
Prerequisites
Time Estimate
30-60 minutes to see productivity improvements
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
mattpocock/skills
parcadei/continuous-claude-v3
cursor/plugins
ailabs-393/ai-labs-claude-skills
pproenca/dot-skills
mattpocock/skills
Registry listing for elasticsearch-authn matched our evaluation — installs cleanly and behaves as described in the markdown.
elasticsearch-authn is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
Solid pick for teams standardizing on skills: elasticsearch-authn is focused, and the summary matches what you get after install.
Keeps context tight: elasticsearch-authn is the kind of skill you can hand to a new teammate without a long onboarding doc.
elasticsearch-authn reduced setup friction for our internal harness; good balance of opinion and flexibility.
We added elasticsearch-authn from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
Useful defaults in elasticsearch-authn — fewer surprises than typical one-off scripts, and it plays nicely with `npx skills` flows.
elasticsearch-authn fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
elasticsearch-authn reduced setup friction for our internal harness; good balance of opinion and flexibility.
elasticsearch-authn has been reliable in day-to-day use. Documentation quality is above average for community skills.
showing 1-10 of 62