Support invalidating multiple API keys by their ID

[cjcenizal]

Is there a way to support invalidating multiple API keys via their IDs with a single request? For example, perhaps we could support comma-separated IDs?

DELETE /_security/api_key
{
  "id" : "key1,key2,key3"
}

CC @bizybot

[jasontedor]

Is it expected that this API would be called in bulk (i.e., with more than a few)? If not, what's the overhead of sending multiple requests, or sending multiple requests in parallel? We aim to keep our APIs and the surface areas of our APIs small, otherwise we bloat how much that we have to maintain.

If we were to enhance this API to allow deleting multiple at once, I wouldn't be in favor using a comma to separate values. We should be explicit that multiple keys are being deleted, something like:

{
  "ids" : [ "key1", "key2", "key3" ]
}

This makes it so much clearer and easier to work with, for clients and us internally.

[elasticmachine]

Pinging @elastic/es-security (:Security/Security)

[elasticmachine]

Pinging @elastic/es-ui (:ES-UI)

[jen-huang]

Hi Security team, the Ingest Management team has a need for bulk invalidate API keys. We expose a UI for taking bulk actions on agents, including bulk unenroll and bulk force unenroll. During force unenrollment, we invalidate two API keys per agent. The user can potentially unenroll up to 10,000 agents at a time using this UI, resulting in the need to invalidate 20,000 keys. As you can probably imagine, sending 20,000 invalidate requests in parallel doesn't work too well today :) Can the team consider re-prioritizing this feature request with this use case in mind? In the meantime I will experiment with batching the requests as our workaround.

cc @ruflin @ph

[bytebilly]

Thanks for raising your use case for this feature.
I think we could reconsider if we want to do that, and which are the implications if we decide to go with it.
Or just see if there is a different solution to solve the problem.

Pinging @elastic/es-security to get more feedback on the technical side of the proposal.

[bytebilly]

We discussed with the team, and we have a few questions about the end to end flow that you expect to see in Fleet.

Given the designs in elastic/kibana#72712, I guess that you expect users to request any possible bulk combination, not just related on policy, or creator. So, existing selectors for bulk invalidate in the invalidate API don't solve the problem.
Is that correct?

Another question is how you get the list of IDs for the selected agents. Is it something that is attached to the agent information? Do you need to fetch them from Elasticsearch? It could be useful to check if there is some optimization for the end to end flow rather than just the invalidate action.

[ph]

@bytebilly I think it could be possible in some cases to optimize the unenrollment, let's say we want to revoke all Agent linked to a specific configuration, maybe we could attach that information as metadata and have the possibility to delete by query, or we could use the "realm_name" for that.

We have to assume that in theory, we could do partial unenroll of Agent from a configuration.

I will let @jen-huang comment on how we get the list of IDs.

[jen-huang]

Hi, you can look at this code branch for the flow: forceUnenrollAgents()

A few key points:

• Agent objects have references to two API key IDs
• Those API keys are always created by the fleet_enroll user (a system user we create) using default_native realm. Thus, it's not possible to invalidate by user or realm because that will invalidate other keys that the user didn't choose.
• The user selection can be done by list of agent IDs, or by query. Regardless, we first fetch all agent objects and from that information, extract all their API key IDs.

Since I last commented, I was able to improve the performance here by batching invalidate requests by ID to 500 keys at a time. This worked well in my local testing and was sufficient for our upper limit of 10,000 agents/20,000 keys.

[bytebilly]

Since I last commented, I was able to improve the performance here by batching invalidate requests by ID to 500 keys at a time. This worked well in my local testing and was sufficient for our upper limit of 10,000 agents/20,000 keys.

Could you please share what your improvements are? How did you implement batching for invalidate by ID? Are you still doing individual invalidate requests for each key, or do you access the security index directly? Thanks!