Elasticsearch API key role_descriptors bounded by creator privileges

Direct answer

Yes. A dedicated low-privileged creator is not required. An administrator—or any identity holding manage_api_key—can create an API key whose permissions are narrower than their own by passing role_descriptors to POST /_security/api_key. When descriptors are present, they replace the default inherited privilege set, and each requested privilege is validated against the creator's effective permissions.

Confirmed behavior and version caveats

Well-established across 7.x and 8.x: without role_descriptors, the key inherits all of the creator's privileges. With descriptors, the key is limited to the specified roles. Validation is strict: a descriptor requesting a cluster privilege, index privilege, or run-as capability that the creator lacks is rejected with an authorization or validation error, not silently truncated.

Version-sensitive: the exact HTTP status and error message text vary by minor release, particularly around 8.x security defaults such as TLS and the security index. Treat any specific error string as requiring verification against your cluster's exact version.

Least-privilege pattern for external integrations

1. Define a dedicated role, for example external_integration_read, granting only read on the required indices.
2. Grant the issuing identity manage_api_key. It does not need superuser access; it only needs the ability to create keys and assign the target role via descriptors.
3. Create the key with explicit role_descriptors referencing that role. The creator's broader privileges are not inherited when descriptors are supplied.
4. Verify effective access by authenticating as the key and testing one allowed operation and one denied operation.

POST /_security/api_key
{
  "name": "external-integration-key",
  "role_descriptors": {
    "external-integration-read": {
      "cluster": [],
      "indices": [
        {
          "names": [ "target-index-*" ],
          "privileges": [ "read" ]
        }
      ]
    }
  }
}

Verification steps

• After creation, inspect GET /_security/api_key to confirm the stored descriptors.
• Use the returned credential in an Authorization header against a read endpoint and a write endpoint to confirm the boundary.
• Run the same test on a cluster with security enabled; security-disabled local clusters skip the authorization path and will not reproduce the validation behavior.

When the recommendation changes

If the creator identity lacks manage_api_key, the request fails with an authorization error before descriptor validation begins. Confirming that the creator holds manage_api_key determines whether you need to adjust the creator's role or only the descriptors; without it, the least-privilege pattern above cannot be applied.