[8.x] [Security Solution] Using API auth for API calls in Serverless Cypress tests (#190152) #199840
Conversation
This file contains 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
…s tests (elastic#190152) ### Context In our Cypress tests, we use API calls to set up the data needed to run the tests. Currently, we are using basic authentication for both ESS and serverless environments. However, for serverless, we should be using API key authentication, especially given that basic authentication will be deprecated soon. ### Challenges * Handling different authentication methods depending on whether the environment is serverless or ESS. * Allowing some tests to access or modify internal indexes. * Managing how the username is handled across different tests. ### Implentation To ensure the correct authentication is used based on the environment where the tests are executed, the `rootRequest` method is used to build the API request. Within this method, the appropriate authentication type is selected. All API calls will use an `admin` API key. The `admin` role is the least restrictive, which is appropriate for setting up data for tests rather than validating application behavior. This role minimizes the risk of issues during setup. A specific challenge arose when we needed to access or modify internal indexes, a capability restricted to the `system_indices_superuser` role for testing purposes. The issue stems from the API key generation method, which is tied to the user's role rather than the user itself. Since serverless currently lacks a role that permits access to internal indexes, we are, upon recommendation from the appex-qa team, using the Elasticsearch client directly with the `system_indices_superuser` role for these scenarios. For tests that assert the username, we made adjustments. Previously, the `system_indices_superuser` role was used universally, which is no longer the case for serverless. We now retrieve the username dynamically from user information instead of hardcoding the value. ### To be discussed When making modifications related to "username", it became apparent that we sometimes use "fullname" and, in other cases, "username," even though they seem intended to represent the same concept. Should we standardize on a single term across the solution? --------- Co-authored-by: kibanamachine <[email protected]> (cherry picked from commit 81af529)
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
💚 Build Succeeded
Metrics [docs]
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Backport
This will backport the following commits from
mainto8.x:Questions ?
Please refer to the Backport tool documentation