API Keys: handle paging through more than 10,000 keys#250826
Merged
legrego merged 15 commits intoelastic:mainfrom Feb 23, 2026
Merged
API Keys: handle paging through more than 10,000 keys#250826legrego merged 15 commits intoelastic:mainfrom
legrego merged 15 commits intoelastic:mainfrom
Conversation
legrego
added
release_note:fix
Team:Security
Contributor
|
Pinging @elastic/kibana-security (Team:Security) |
jeramysoucy
reviewed
Feb 12, 2026
Contributor
jeramysoucy
left a comment
jeramysoucy
left a comment
There was a problem hiding this comment.
Overal LGTM - just a nit and a questions. I tested this manually using a script to generate massive amounts of API keys and everything worked as expected.
x-pack/platform/plugins/shared/security/server/routes/api_keys/query.ts
Outdated
Show resolved
Hide resolved
jeramysoucy
approved these changes
Feb 13, 2026
Contributor
jeramysoucy
left a comment
jeramysoucy
left a comment
There was a problem hiding this comment.
LGTM! Thanks for the update!
miguelmartin-elastic
approved these changes
Feb 18, 2026
Contributor
miguelmartin-elastic
left a comment
miguelmartin-elastic
left a comment
There was a problem hiding this comment.
For files owned by obs-actionable-team, changes look good to me🚀
The only change is in x-pack/solutions/observability/test/api_integration_deployment_agnostic/apis/synthetics/synthetics_enablement.ts, so if the integ test passes we're safe.
Ty!
legrego
added
backport:version
Contributor
⏳ Build in-progress, with failures
Failed CI StepsTest Failures
History
|
Contributor
|
Starting backport for target branches: 8.19, 9.3 |
kibanamachine
pushed a commit
to kibanamachine/kibana
that referenced
this pull request
Feb 23, 2026
## Summary This pull request refactors API key management pagination to use Elasticsearch's `search_after` cursor-based pagination instead of traditional page indices. It updates the API, UI state, and tests to support this approach, so that the UI can accommodate clusters with more than 10,000 API Keys. Resolves elastic#250625 > [!IMPORTANT] > This results in a design tradeoff. The previous screen had pages of results that users could click through: `Pages: 1, 2, 3, ..., 10`. The new screen does not allow users to jump to an arbitrary page, because that functionality is not possible when using cursor-based pagination. <img width="1375" height="1322" alt="Larry Gregory 2026-02-11 at 10 43 09" src="https://github.com/user-attachments/assets/e041995b-e342-4a62-851e-5ff11116585c" /> (cherry picked from commit 6cb0bbf)
Contributor
💔 Some backports could not be created
Note: Successful backport PRs will be merged automatically after passing CI. Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
Member
Author
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
legrego
added a commit
to legrego/kibana
that referenced
this pull request
Feb 23, 2026
## Summary This pull request refactors API key management pagination to use Elasticsearch's `search_after` cursor-based pagination instead of traditional page indices. It updates the API, UI state, and tests to support this approach, so that the UI can accommodate clusters with more than 10,000 API Keys. Resolves elastic#250625 > [!IMPORTANT] > This results in a design tradeoff. The previous screen had pages of results that users could click through: `Pages: 1, 2, 3, ..., 10`. The new screen does not allow users to jump to an arbitrary page, because that functionality is not possible when using cursor-based pagination. <img width="1375" height="1322" alt="Larry Gregory 2026-02-11 at 10 43 09" src="https://github.com/user-attachments/assets/e041995b-e342-4a62-851e-5ff11116585c" /> (cherry picked from commit 6cb0bbf) # Conflicts: # x-pack/platform/plugins/private/translations/translations/de-DE.json # x-pack/platform/plugins/private/translations/translations/fr-FR.json # x-pack/platform/plugins/private/translations/translations/zh-CN.json
kibanamachine
added a commit
that referenced
this pull request
Feb 23, 2026
…#254572) # Backport This will backport the following commits from `main` to `9.3`: - [API Keys: handle paging through more than 10,000 keys (#250826)](#250826) <!--- Backport version: 9.6.6 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Larry Gregory","email":"larry.gregory@elastic.co"},"sourceCommit":{"committedDate":"2026-02-23T18:21:19Z","message":"API Keys: handle paging through more than 10,000 keys (#250826)\n\n## Summary\n\nThis pull request refactors API key management pagination to use\nElasticsearch's `search_after` cursor-based pagination instead of\ntraditional page indices. It updates the API, UI state, and tests to\nsupport this approach, so that the UI can accommodate clusters with more\nthan 10,000 API Keys.\n\nResolves https://github.com/elastic/kibana/issues/250625\n\n\n> [!IMPORTANT]\n> This results in a design tradeoff. The previous screen had pages of\nresults that users could click through: `Pages: 1, 2, 3, ..., 10`. The\nnew screen does not allow users to jump to an arbitrary page, because\nthat functionality is not possible when using cursor-based pagination.\n\n\n<img width=\"1375\" height=\"1322\" alt=\"Larry Gregory 2026-02-11 at 10 43\n09\"\nsrc=\"https://github.com/user-attachments/assets/e041995b-e342-4a62-851e-5ff11116585c\"\n/>","sha":"6cb0bbf16bf4ca6f2e6b4b2491a97aa2a7084a28","branchLabelMapping":{"^v9.4.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","Team:Security","Feature:Users/Roles/API Keys","backport:version","v9.4.0","v9.3.1","v8.19.12"],"title":"API Keys: handle paging through more than 10,000 keys","number":250826,"url":"https://github.com/elastic/kibana/pull/250826","mergeCommit":{"message":"API Keys: handle paging through more than 10,000 keys (#250826)\n\n## Summary\n\nThis pull request refactors API key management pagination to use\nElasticsearch's `search_after` cursor-based pagination instead of\ntraditional page indices. It updates the API, UI state, and tests to\nsupport this approach, so that the UI can accommodate clusters with more\nthan 10,000 API Keys.\n\nResolves https://github.com/elastic/kibana/issues/250625\n\n\n> [!IMPORTANT]\n> This results in a design tradeoff. The previous screen had pages of\nresults that users could click through: `Pages: 1, 2, 3, ..., 10`. The\nnew screen does not allow users to jump to an arbitrary page, because\nthat functionality is not possible when using cursor-based pagination.\n\n\n<img width=\"1375\" height=\"1322\" alt=\"Larry Gregory 2026-02-11 at 10 43\n09\"\nsrc=\"https://github.com/user-attachments/assets/e041995b-e342-4a62-851e-5ff11116585c\"\n/>","sha":"6cb0bbf16bf4ca6f2e6b4b2491a97aa2a7084a28"}},"sourceBranch":"main","suggestedTargetBranches":["9.3","8.19"],"targetPullRequestStates":[{"branch":"main","label":"v9.4.0","branchLabelMappingKey":"^v9.4.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/250826","number":250826,"mergeCommit":{"message":"API Keys: handle paging through more than 10,000 keys (#250826)\n\n## Summary\n\nThis pull request refactors API key management pagination to use\nElasticsearch's `search_after` cursor-based pagination instead of\ntraditional page indices. It updates the API, UI state, and tests to\nsupport this approach, so that the UI can accommodate clusters with more\nthan 10,000 API Keys.\n\nResolves https://github.com/elastic/kibana/issues/250625\n\n\n> [!IMPORTANT]\n> This results in a design tradeoff. The previous screen had pages of\nresults that users could click through: `Pages: 1, 2, 3, ..., 10`. The\nnew screen does not allow users to jump to an arbitrary page, because\nthat functionality is not possible when using cursor-based pagination.\n\n\n<img width=\"1375\" height=\"1322\" alt=\"Larry Gregory 2026-02-11 at 10 43\n09\"\nsrc=\"https://github.com/user-attachments/assets/e041995b-e342-4a62-851e-5ff11116585c\"\n/>","sha":"6cb0bbf16bf4ca6f2e6b4b2491a97aa2a7084a28"}},{"branch":"9.3","label":"v9.3.1","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"},{"branch":"8.19","label":"v8.19.12","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT--> Co-authored-by: Larry Gregory <larry.gregory@elastic.co>
legrego
added a commit
that referenced
this pull request
Feb 23, 2026
#254575) # Backport This will backport the following commits from `main` to `8.19`: - [API Keys: handle paging through more than 10,000 keys (#250826)](#250826) <!--- Backport version: 10.2.0 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sorenlouv/backport) <!--BACKPORT [{"author":{"name":"Larry Gregory","email":"larry.gregory@elastic.co"},"sourceCommit":{"committedDate":"2026-02-23T18:21:19Z","message":"API Keys: handle paging through more than 10,000 keys (#250826)\n\n## Summary\n\nThis pull request refactors API key management pagination to use\nElasticsearch's `search_after` cursor-based pagination instead of\ntraditional page indices. It updates the API, UI state, and tests to\nsupport this approach, so that the UI can accommodate clusters with more\nthan 10,000 API Keys.\n\nResolves https://github.com/elastic/kibana/issues/250625\n\n\n> [!IMPORTANT]\n> This results in a design tradeoff. The previous screen had pages of\nresults that users could click through: `Pages: 1, 2, 3, ..., 10`. The\nnew screen does not allow users to jump to an arbitrary page, because\nthat functionality is not possible when using cursor-based pagination.\n\n\n<img width=\"1375\" height=\"1322\" alt=\"Larry Gregory 2026-02-11 at 10 43\n09\"\nsrc=\"https://github.com/user-attachments/assets/e041995b-e342-4a62-851e-5ff11116585c\"\n/>","sha":"6cb0bbf16bf4ca6f2e6b4b2491a97aa2a7084a28","branchLabelMapping":{"^v9.4.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["release_note:fix","Team:Security","Feature:Users/Roles/API Keys","backport:version","v9.4.0","v9.3.1","v8.19.12"],"title":"API Keys: handle paging through more than 10,000 keys","number":250826,"url":"https://github.com/elastic/kibana/pull/250826","mergeCommit":{"message":"API Keys: handle paging through more than 10,000 keys (#250826)\n\n## Summary\n\nThis pull request refactors API key management pagination to use\nElasticsearch's `search_after` cursor-based pagination instead of\ntraditional page indices. It updates the API, UI state, and tests to\nsupport this approach, so that the UI can accommodate clusters with more\nthan 10,000 API Keys.\n\nResolves https://github.com/elastic/kibana/issues/250625\n\n\n> [!IMPORTANT]\n> This results in a design tradeoff. The previous screen had pages of\nresults that users could click through: `Pages: 1, 2, 3, ..., 10`. The\nnew screen does not allow users to jump to an arbitrary page, because\nthat functionality is not possible when using cursor-based pagination.\n\n\n<img width=\"1375\" height=\"1322\" alt=\"Larry Gregory 2026-02-11 at 10 43\n09\"\nsrc=\"https://github.com/user-attachments/assets/e041995b-e342-4a62-851e-5ff11116585c\"\n/>","sha":"6cb0bbf16bf4ca6f2e6b4b2491a97aa2a7084a28"}},"sourceBranch":"main","suggestedTargetBranches":["8.19"],"targetPullRequestStates":[{"branch":"main","label":"v9.4.0","branchLabelMappingKey":"^v9.4.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/250826","number":250826,"mergeCommit":{"message":"API Keys: handle paging through more than 10,000 keys (#250826)\n\n## Summary\n\nThis pull request refactors API key management pagination to use\nElasticsearch's `search_after` cursor-based pagination instead of\ntraditional page indices. It updates the API, UI state, and tests to\nsupport this approach, so that the UI can accommodate clusters with more\nthan 10,000 API Keys.\n\nResolves https://github.com/elastic/kibana/issues/250625\n\n\n> [!IMPORTANT]\n> This results in a design tradeoff. The previous screen had pages of\nresults that users could click through: `Pages: 1, 2, 3, ..., 10`. The\nnew screen does not allow users to jump to an arbitrary page, because\nthat functionality is not possible when using cursor-based pagination.\n\n\n<img width=\"1375\" height=\"1322\" alt=\"Larry Gregory 2026-02-11 at 10 43\n09\"\nsrc=\"https://github.com/user-attachments/assets/e041995b-e342-4a62-851e-5ff11116585c\"\n/>","sha":"6cb0bbf16bf4ca6f2e6b4b2491a97aa2a7084a28"}},{"branch":"9.3","label":"v9.3.1","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"url":"https://github.com/elastic/kibana/pull/254572","number":254572,"state":"OPEN"},{"branch":"8.19","label":"v8.19.12","branchLabelMappingKey":"^v(\\d+).(\\d+).\\d+$","isSourceBranch":false,"state":"NOT_CREATED"}]}] BACKPORT-->
bhapas
pushed a commit
to bhapas/kibana
that referenced
this pull request
Feb 25, 2026
## Summary This pull request refactors API key management pagination to use Elasticsearch's `search_after` cursor-based pagination instead of traditional page indices. It updates the API, UI state, and tests to support this approach, so that the UI can accommodate clusters with more than 10,000 API Keys. Resolves elastic#250625 > [!IMPORTANT] > This results in a design tradeoff. The previous screen had pages of results that users could click through: `Pages: 1, 2, 3, ..., 10`. The new screen does not allow users to jump to an arbitrary page, because that functionality is not possible when using cursor-based pagination. <img width="1375" height="1322" alt="Larry Gregory 2026-02-11 at 10 43 09" src="https://github.com/user-attachments/assets/e041995b-e342-4a62-851e-5ff11116585c" />
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This pull request refactors API key management pagination to use Elasticsearch's
search_aftercursor-based pagination instead of traditional page indices. It updates the API, UI state, and tests to support this approach, so that the UI can accommodate clusters with more than 10,000 API Keys.Resolves #250625
Important
This results in a design tradeoff. The previous screen had pages of results that users could click through:
Pages: 1, 2, 3, ..., 10. The new screen does not allow users to jump to an arbitrary page, because that functionality is not possible when using cursor-based pagination.