Elastic package v1.0.0

An Elasticsearch API key for the customer's own deployment, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'ApiKey', one separating space, then the Base64-encoded 'id:api_key' pair as returned at creation — 'ApiKey <base64>'.

Issuance is external: a user with the manage_api_key or manage_own_api_key cluster privilege (or an Elastic Cloud org admin through the Cloud console) creates the key via the create API key API or Kibana, and the Base64 value is shown once at creation, so capture it into the vault at that moment.

Credential type: this reference takes an ELASTICSEARCH API key created against the customer's deployment (or Elastic Cloud Serverless project); an Elastic Cloud ORGANIZATION-management API key, which manages Cloud resources through the Cloud API rather than cluster data, is a different credential and cannot serve these endpoints. Least privilege, per operation: the _cat/indices collection read additionally requires the index-level monitor privilege on the bound indices — according to the reviewed security-privileges reference, index-level monitor covers monitoring actions on those indices; the search read needs the read index privilege on the bound indices; document indexing needs the index privilege (create_doc is insufficient because the registered PUT can overwrite an existing document id, and write would also grant document deletion, which this pack does not register); index creation needs create_index; index deletion needs delete_index; and delete_by_query needs read on the target indexes in addition to the delete index privilege — grant only the privileges the enabled capabilities need, scoped to the concrete index names the deployment binds, plus view_index_metadata where metadata columns are required.

Expiry and revocation: an API key can be created with an expiration, after which it fails closed, but a key created without one does not expire on its own; revocation is explicit invalidation through the invalidate API key API or Kibana, and disabling issuance — for example removing the privilege that lets a role create keys, or turning off the API key service — does not invalidate keys already issued: each issued key must be invalidated individually.

Rotation and renewal therefore sit with an external deployment process: the executor injects the stored value verbatim and performs no key lifecycle of its own. Elasticsearch also accepts Basic auth with a native username and password; this pack registers the ApiKey header because API keys are scoped and individually revocable in a way a shared native password is not.

Executor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack.

The endpoint host 'elastic-cluster.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the customer's own Elasticsearch endpoint — the Elastic Cloud deployment's Elasticsearch URL, an Elastic Cloud Serverless project endpoint, or a self-managed cluster host — before enabling, in every endpoint, in the resource locator and in every egress allowlist entry. The allowlist matches exactly, so endpoints and allowlist must be substituted together, and substitution is a required deployment step — the reserved host being allowlisted does not make an unsubstituted pack safe to enable. INDEX and DOC_ID in the endpoint paths are placeholders the deployment binds to concrete index names and document ids before enabling.

The search capability is a POST because Elasticsearch's search API takes the query in the request body; the registered effect is a read-only search, but the body is an unrestricted Elasticsearch Query DSL document (query, from, size, sort, aggregations, _source filtering and more, according to the reviewed search API reference), so this registration does not restrict which indices' fields a query may read beyond the INDEX path placeholder, and a deployment that needs field- or document-level restriction must enforce it in the API key's role descriptors, not in this pack.

Approval classification: delete_by_query is registered as delete at the minimum R3 tier, not as a query, because its effect is document deletion — a match_all body deletes every document in the target index — and delete is one of the designated actions requiring human approval. Index deletion is registered as delete at the minimum R3 tier; according to the reviewed delete-index API reference, the index path parameter does not support wildcards or _all unless the cluster sets action.destructive_requires_name to false, and this pack registers concrete-index deletion only.

Document indexing (PUT /INDEX/_doc/DOC_ID) is registered as create and update at the minimum R2 tier: indexing with an existing id overwrites the previous document, and according to the reviewed privileges reference the index API allows overwriting, so this is not a create-only registration.

Excluded operations: the security APIs (users, roles, role mappings, API key creation/invalidation, service accounts), snapshot and restore, index lifecycle management, index settings and mapping updates, index templates, reindex (which copies data between indices, including cross-cluster), cluster settings updates and cluster reroute, ingest pipelines, machine learning APIs, watcher, _bulk (whose unrestricted body mixes index, create, update and delete operations in one request and would defeat any single-action registration), single-document get (GET /INDEX/_doc/DOC_ID), single-document delete (DELETE /INDEX/_doc/DOC_ID), and every other Elasticsearch API.