[FTR] allow to call roleScopedSupertest service with Cookie header

[dmlemeshko]

Summary

During the sync with kibana-security team we agreed on how Kibana APIs should be tested:

API Authentication in Kibana: Public vs. Internal APIs

Kibana provides both public and internal APIs, each requiring authentication with the correct privileges. However, the method of testing these APIs varies, depending on how they are untilized by end users.

• Public APIs: When testing HTTP requests to public APIs, API key-based authentication should be used. It reflect how end user call these APIs. Due to existing restrictions, we utilize Admin user credentials to generate API keys for various roles. While the API key permissions are correctly scoped according to the assigned role, the user will internally be recognized as Admin during authentication.

• Internal APIs: Direct HTTP requests to internal APIs are generally not expected. However, for testing purposes, authentication should be performed using the Cookie header. This approach simulates client-side behavior during browser interactions, mirroring how internal APIs are indirectly invoked.

To simplify the process of creating/updating the tests, this PR makes few changes to roleScopedSupertest service

1. testing public APIs (nothing changed)

      const supertestAdminWithApiKey = await roleScopedSupertest.getSupertestWithRoleScope('admin', {
        withCustomHeaders: { 'accept-encoding': 'gzip' },
      });
      const response = await supertestAdminWithApiKey.get('/app/kibana');

2. testing internal APIs

      const  supertestAdminWithCookieCredentials = await roleScopedSupertest.getSupertestWithRoleScope(
        'admin',
        {
          useCookieHeader: true, // will use Cookie header instead of API key
          withInternalHeaders: true,
        }
      );
      await supertestAdminWithCookieCredentials
        .post(`/internal/kibana/settings/${TEST_SETTING}`)
        .send({ value: 100 })
        .expect(200);

I updated some of the existing tests according to the new approach.

Docs for serverless and deployment-agnostic api integration tests were updated accordingly

[dmlemeshko]

Since all the APIs in this suite are internal, we use supertest scoped to Admin role and cookie header for auth

[dmlemeshko]

Since all the APIs in this suite are internal, we use supertest scoped to Admin role and cookie header for auth

[dmlemeshko]

Since all the APIs in this suite are internal, we use supertest scoped to Admin role and cookie header for auth. Repeated headers moved directly to scoped supertest creation.

[shahzad31]

LGTM !!

[pheyos]

LGTM

[jeramysoucy]

LGTM! Just found one missed change. Thanks for making these updates, Dima!

[jeramysoucy]

Looks like this one was missed

Suggested change

	({ body, status } = await supertestWithoutAuth
	({ body, status } = await supertestAdminWithCookieCredentials

[dmlemeshko]

But this scenario is testing the case without auth: we suppose to get 401.

On main we don't set API key header https://github.com/elastic/kibana/blob/main/x-pack/test_serverless/api_integration/test_suites/common/platform_security/api_keys.ts#L69-L79

Should I keep it as is?

[jeramysoucy]

Ah I see. I think that was maybe unintentional, looking at the comment

// expect a rejection because we're not using the internal header

I think the test was intended to fail for not utilizing the internal header, like with the other test cases.
But, this is on our team, not yours. I don't want to hold up your PR. I can fix this when I open a PR to adjust the access level for some of our other endopints.

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 2899971

Metrics [docs]

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/ftr-common-functional-services	81	83	+2

Unknown metric groups

API count

id	before	after	diff
@kbn/ftr-common-functional-services	106	108	+2

History

• 💔 Build #235593 failed bf921ee
• 💔 Build #235538 failed 4966103
• 💛 Build #235475 was flaky 16cf8e7
• 💛 Build #235377 was flaky a762679
• 💔 Build #235259 failed 27153d3

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @dmlemeshko

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	8.x

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation