-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Advanced API Key invalidation #53868
Comments
Pinging @elastic/kibana-alerting-services (Team:Alerting Services) |
Some quick notes: To solve this, we may have to create an API key from the alert's API key (similar to a token) and delete it after the alert / action finished execution. We may also have to create a new API key for each action scheduled from an alert to know that when the API key is deleted, we're really done with it. The mechanism to |
Turns out using API keys to create sub API keys doesn't work when using Kibana to create them on behalf of other users. This leaves a few alternatives worth thinking about but I believe we may hold off until this becomes a more severe issue. The best scenario to describe the issue is when an alert or action is taking a while to run and the alert gets updated, the API key no longer works half way through. 1. Queue the API key for invalidationThe way I'm thinking, it would involve the following changes from a high level:
This one will require a saved object migration on 2. Look into allowing this scenario (API keys creating sub API keys)?To allow API keys to create another API key. This would require external dependencies and research to see if this is worth pursuing. 3. Look into using a token service?I'm not too familiar with it but it requires https://www.elastic.co/guide/en/elasticsearch/reference/master/token-authentication-services.html 4. Leave functionality as isProbably the option for now until we need to solve it with a scenario like above or others. Will mark issue as blocked / discuss for now. |
Does the API key no longer work because it was explicitly invalidated by the user? If so, we can only assume the intent is to prevent it from being used for authentication, so having it fail mid-way through processing the alert makes sense. Users are able to invalidate API Keys using Elasticsearch APIs, and we can't prevent users from directly invalidating API Keys using those APIs and force them to be queued until they're no longer used. If we tried to circumvent this by cloning the API Key, the clone could just be invalidated also. |
That is definitely one use case which we won't be able to protect ourselves from as you mention. The other scenario is more when users are updating alerts. We immediately create a new API key and invalidate the old one (here: https://github.com/elastic/kibana/blob/master/x-pack/plugins/alerting/server/alerts_client.ts#L300). If the alert was running or had pending / running actions, those are all possible scenarios that could fail due to referencing a now invalidated API key from an update. The alert would recover from this scenario at the next execution / interval. Some actions may fail to run and not re-try due to always having a reference to an old API key. |
Gotcha, that makes sense. Thanks for explaining. 🤔 |
This is an interesting proposal. It seems somewhat complicated, but seems feasible.
I've proposed adding the ability to allow API Keys to optionally clone themselves to enable other features in the past. We ended up not going this approach, but it's worth exploring.
The Get token API is primarily consumed by Kibana's auth providers internally to support features like SAML, OIDC, Kerberos, etc. Unfortunately, it's not possible to have an APIKey and use this to get a token.
This is somewhat limiting, and it could be a potentially frustrating UX. However, we could use optimistic concurrency control to make sure that we can update the API Key which will be used before invalidating it, to ensure it didn't start running during the process. |
This sounds interesting. How would the OCC work, would it be with the task in Task Manager? |
I created an issue within Elasticsearch repo to explore option 2. |
We'll have to come up with a different approach based on timing. I'm thinking of a new option where we just delete the API key at a future time by using task manager. The API key ID for deletion can be stored in a saved object and either a single task manager task or one-per API key would execute the cleanup. If ever something was to fail after this fixed deletion time, we could consider this the same scenario as a user manually deleting the API key and leave the functionality as is for now. |
After discussion we decided to investigate the two approaches:
|
Once the simple invalidation of API keys is resolved (#45144), there will still be some cases that errors may happen and should be solved in this issue.
The extra cases are:
The text was updated successfully, but these errors were encountered: