An Elasticsearch API key can look like a standalone credential, especially when an automation stores it in a secret manager. The key is not an independent superuser. It represents a principal and can carry role descriptors that narrow access. Teams should review both the requested key permissions and the permissions of the user who created it.
The effective permission set
Elastic documents API keys as a way to authenticate and authorize requests to Elasticsearch resources. For a user API key, the creator can choose predefined roles or custom privileges. Role descriptors on the key limit the resulting permissions. The documented result is an intersection: the key cannot have more access than the authenticated user who created it.
That intersection is useful, but it has two sides. A narrowly scoped key created by a broad administrator may still be safe for the automation if the descriptor is correct. A key with broad descriptors created by a restricted user remains bounded by the user, but the descriptor can be wider than the task requires. Review the descriptor instead of assuming that the key's label describes its access.
The Create API key API also notes that an API key without an expiration does not expire. Long-lived inventory can accumulate after scripts are retired. Keys should have an owner, a purpose, a creation time, and an expected review date.
Separate key management from key use
Creating and managing keys requires security privileges such as manage_api_key or manage_own_api_key, depending on the operation. A service that only needs to read one index should not also be able to create new keys for itself. If a compromised application can mint a key with broader access, the initial key scope becomes less important.
Use a dedicated control-plane identity for key lifecycle work and a separate data-plane identity for normal requests. If the application runtime does not need key-management permissions, remove them. For cross-cluster keys, the privilege and licensing requirements are different again, so the review must match the exact key type.
Make rotation observable
Inventory keys by name, creation time, owner, roles, and last use where the deployment exposes it. A key with no known owner is a cleanup candidate. A key used only by a retired pipeline is not made safer by keeping it indefinitely. Invalidate the key before deleting the application credentials that might still use it, then confirm that the application has moved to the replacement.
The Elasticsearch API key page also separates the ability to view keys from the ability to manage them. A read-only security role can inspect key metadata without granting permission to create or delete keys. That separation helps an audit team verify the inventory without making every auditor a key administrator.
Test the boundary with real requests
Create a test key with the smallest role descriptor the workload claims to need. Send a permitted request and several denied requests. Include an index outside the allowed pattern, an administrative endpoint, and a security endpoint. The denied responses should come from authorization, not from a malformed request.
Then repeat the check with a key created by a less privileged user. Confirm that the effective intersection is what the design documents. Test expiration and invalidation. A key that has been deleted from the inventory but remains accepted by the cluster is still a live credential.
Elasticsearch gives operators precise building blocks for API-key permissions. The useful review asks what the key can do, who can create it, and whether anyone is watching its lifecycle. Those questions remain after the initial setup is complete.