-
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
[POC] Serverless API integration test helper - create API key as admin #184948
Comments
Pinging @elastic/kibana-security (Team:Security) |
…tor privileges (#185870) ## Summary * ***Create a new service that replaced the serverless `supertest` with a custom implementation that adds auth headers*** * `username` updates * Update `SessionManager` to store `username` * Create and export `securitySolutionUtils` to return the `username` * Update tests to use the `getUsername` helper * Create a helper that allows switching serverless roles on a test ```js export default ({ getService }: FtrProviderContext) => { const utils = getService('securitySolutionUtils'); describe('@ess @serverless my_test', () => { let supertest: TestAgent; before(async () => { supertest = await utils.createSuperTest('admin'); }); ... ``` * Update FTR tests [README file](https://github.com/machadoum/kibana/blob/siem-ea-183512/x-pack/test/security_solution_api_integration/README.md#testing-with-serverless-roles) with further details Flaky test runner: https://buildkite.com/elastic/kibana-flaky-test-suite-runner/builds/6320 ### Know issues * Currently `utils.createSuperTest('viewer')` fails on the API creation. It will be fixed by @elastic/kibana-security #184948 ### Checklist Delete any items that are not applicable to this PR. - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] [Flaky Test Runner](https://ci-stats.kibana.dev/trigger_flaky_test_runner/1) was used on any tests changed
@jeramysoucy This issue came across my radar as I've been asking questions about how to re-enable a certain test for Reporting: #186558. The background is: I have an API integration test in the stateful area that I wish to carry into serverless. The test involves 2 users: UserA and UserB.
Will it be possible to create a test like this for serverless?
|
@tsullivan Let me make sure I first understand correctly. You want to create an API integration test that confirms that only the creator of a report can see/delete that report. Is that accurate? I don't think this is currently possible in serverless, as API keys are created on the fly for a specific role, and not for/by a specific user. |
@jeramysoucy you understand correctly. Thank you for the clarification! |
@tsullivan No problem. How do we assign ownership of a report when it is generated via API with API key auth? I assume we have to use the API key owner as the report owner. |
Description
To support moving away from using basic authentication when testing API endpoints in serverless, we created an FTR helper for creating an API key for a specific role by name (
SvlUserManagerProvider.createApiKeyForRole
). The helper authenticates as a user with the named role and creates an API key. However, it turns out that many roles are unable to create an API key, but are expected to be able to access some subset of APIs.To keep the helper easy to use and understand, we are going to create a POC that explores the idea of using an admin account to create the role-specific API key. In order to do this, we will need to read the permissions granted to the named role from the project-specific
roles.yml
file (which I think we can withreadRolesFromResource
). These permissions will be used in the role descriptor, combined with a default of no privileges for each category.This will allow maintainers of API tests to test all of their API endpoints with specific roles, and not have to worry about the underlying method of authentication, or whether a role grants the privilege to create an API key.
Further thoughts
Ideally, we will rename our FTR authentication helpers more explicitly, to imply the appropriate use case. e.g...
cc @azasypkin @pheyos
The text was updated successfully, but these errors were encountered: