Hi Elastic team/community,
While reviewing API Keys in Kibana, I noticed that the flag used to identify Managed API keys (created/used by Kibana background tasks) can be overwritten by a user by editing the API key metadata. This can cause keys to be misclassified or hidden when operators rely on “managed vs non-managed” filtering in the Kibana UI.
Elastic docs describe Managed API keys as “created and managed by Kibana to run background tasks.” (refer to Elastic)
At the same time, the Update API key API explicitly allows updating metadata and states that new metadata fully replaces existing metadata. (refer to Elastic)
Also, metadata is arbitrary and only keys starting with _ are reserved for system usage. (refer to Elastic)
Why this matters
In practice, admins often filter out “managed” keys because they assume those are system-generated and not something to review. If a user can set metadata.managed: true (or remove/flip it), then the “managed” label/filter becomes user-controlled, which can lead to operational blind spots during reviews.
Steps to reproduce (what I did)
-
Go to Stack Management → API Keys.
-
Create an API key setting the metadata field
managedtotrue -
Observe that the key’s “managed-ness” and visibility changes when filtering/searching based on
metadata.managed.
Expected behavior
Either:
-
Kibana should not rely on user-editable metadata to classify “Managed API keys”, or
-
Kibana should prevent editing the field that controls “managed” classification (or warn loudly), or
-
Managed-ness should be based on an immutable/system-controlled attribute (or a system-reserved metadata key) rather than a plain
metadata.managedkey.
Environment
-
Deployment: Elastic Cloud Hosted
-
Stack version: [v 9.2.1]
-
Role/privileges used: [e.g., manage_api_key / manage_own_api_key]
Questions
-
Is
metadata.managedintended to be the source-of-truth for Kibana’s “Managed API keys” filter? -
If yes, is it expected that a user can set/unset it and affect classification?
Thanks!