Skip to content
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

Closed
jeramysoucy opened this issue Jun 6, 2024 · 5 comments · Fixed by #188102
Closed

[POC] Serverless API integration test helper - create API key as admin #184948

jeramysoucy opened this issue Jun 6, 2024 · 5 comments · Fixed by #188102
Assignees
Labels
Feature:Security/Authentication Platform Security - Authentication Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!

Comments

@jeramysoucy
Copy link
Contributor

jeramysoucy commented Jun 6, 2024

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 with readRolesFromResource). 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...

  • createApiKeyForRole -> createM2mApiKeyWithRoleScope
  • getSessionCookieForRole -> getInteractiveUserSessionCookieWithRoleScope

cc @azasypkin @pheyos

@jeramysoucy jeramysoucy added Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more! Feature:Security/Authentication Platform Security - Authentication labels Jun 6, 2024
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-security (Team:Security)

machadoum added a commit that referenced this issue Jun 25, 2024
…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
@tsullivan
Copy link
Member

@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.

  • UserA creates a report
  • UserB attempts to delete the report but is given a 404 response.

Will it be possible to create a test like this for serverless?

  • I have tried creating two sets of API Key credentials using SvlUserManagerProvider.createApiKeyForRole multiple times (ApiKeyA, ApiKeyB). That didn't work: Kibana seems to treat requests from ApiKeyA and ApiKeyB as belonging to the same user.
  • I have tried creating an API Key for an admin account and an API Key for a non-admin account, but that didn't work as right now only admin is available.

@jeramysoucy jeramysoucy self-assigned this Jul 9, 2024
@jeramysoucy
Copy link
Contributor Author

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.

UserA creates a report
UserB attempts to delete the report but is given a 404 response.
Will it be possible to create a test like this for serverless?

I have tried creating two sets of API Key credentials using SvlUserManagerProvider.createApiKeyForRole multiple times (ApiKeyA, ApiKeyB). That didn't work: Kibana seems to treat requests from ApiKeyA and ApiKeyB as belonging to the same user.
I have tried creating an API Key for an admin account and an API Key for a non-admin account, but that didn't work as right now only admin is available.

@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.

@tsullivan
Copy link
Member

@jeramysoucy you understand correctly. Thank you for the clarification!

@jeramysoucy
Copy link
Contributor Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Security/Authentication Platform Security - Authentication Team:Security Team focused on: Auth, Users, Roles, Spaces, Audit Logging, and more!
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants