[NP] Hide Authorization header on KibanaRequest

[mshustov]

The proxy project was suspended indefinitely. We should revert #39506 to prevent plugins from accessing the Authorization header.

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[pgayvallet]

Isn't this going to be blocker for plugins that actually relies on accessing the Authorization header? To my knowledge, this is how reporting works to store the user credentials to be able to generate their reports.

@tsullivan Could you confirm/infirm that?

[mshustov]

Isn't this going to be blocker for plugins that actually relies on accessing the Authorization header

It might require additional work from the platform team to provide an alternative solution, but restricting access to the Authorization header is a requirement from @elastic/kibana-security .

[pgayvallet]

It might require additional work from the platform team to provide an alternative solution, but restricting access to the Authorization header is a requirement from @elastic/kibana-security .

I understand the need and concern regarding security. However, accessing them is a blocking requirement for (at least) reporting. We can't implement this before having a proper alternative to answer the plugins' need.

@elastic/kibana-security Do you have any suggestion on how plugins such as reporting should be accessing the Authz headers after this change?

One example in
x-pack/legacy/plugins/reporting/server/routes/generate_from_savedobject_immediate.ts
x-pack/legacy/plugins/reporting/export_types/csv_from_savedobject/server/create_job/create_job.ts

      const jobDocPayload: JobDocPayloadPanelCsv = await createJobFn(
        jobParams,
        request.headers, // <---
        request
      );

  return async function createJob(
    jobParams: JobParamsPanelCsv,
    headers: any,
    req: RequestFacade
  ): Promise<JobDocPayloadPanelCsv> {
    const { savedObjectType, savedObjectId } = jobParams;
    const serializedEncryptedHeaders = await crypto.encrypt(headers); // <---

[tsullivan]

To my knowledge, this is how reporting works to store the user credentials to be able to generate their reports.

That is correct, and thank you so much for catching this, @pgayvallet

Reporting captures the request headers from the user that created the reporting job through the UI. The headers are encrypted, and stored in the reporting job document in .reporting-* When the job is claimed, the headers are decrypted, and passed along with every headless browser request that goes to the Kibana server origin.

Sources:

• PDF capture headers: https://github.com/elastic/kibana/blob/e8b859b/x-pack/legacy/plugins/reporting/export_types/printable_pdf/server/create_job/index.ts#L28
• Headless browser inject headers: https://github.com/elastic/kibana/blob/e8b859b/x-pack/legacy/plugins/reporting/server/browsers/chromium/driver/chromium_driver.ts#L94

[mshustov]

@pmuellr could it affect alerting plugin somehow? As I can see you use ApiKey, asking if I missed something

kibana/x-pack/legacy/plugins/alerting/server/task_runner/task_runner.ts

Line 68 in 9d4414d

headers: requestHeaders,

[pmuellr]

Yes, I think it will, as we "fake request" things with an API key - @mikecote is more familiar with these bits than I.

Just in general, we're find clients of alerting wanting more and more access to things that they normally get off a request, but are needed when the alert function runs, in the background, without an active request available. The last request was for uiSettings (legacy), which is fairly easily accommodated by creating one by hand with our "fake" SO client (which we already provide).

Seems like the right answer is to provide 1st class support for creating a "request" object that alerting can hand to the alert functions, outside of the context of an incoming http request. We already have the space and API key, not sure what else would be required to create one of these - let's call it "transactional request object". It would then need to be augmented with all the other context-y bits. Certainly, it's a separate issue :-) . Or do we already have a similar issue open somewhere?

I wonder if Make It Slow impacts this stuff as well? Seems like that could have similar issues - wanting to run some user-specific Kibana code long after some "slow" transaction was started with an http request to Kibana.

[mikecote]

We create fake requests with authorization headers to access a scoped saved objects client and a scoped admin client (Elasticsearch). Once we pass the request to those, we no longer need to access the authorization headers. @pmuellr is right where we may later on need more features that are scoped to the user without a real request.

Usage here:

kibana/x-pack/legacy/plugins/alerting/server/plugin.ts

Lines 133 to 137 in 9d4414d

	return {
	callCluster: (...args) => adminClient!.asScoped(request).callAsCurrentUser(...args),
	// rawRequest is actually a fake request, converting it to KibanaRequest causes issue in SO access
	savedObjectsClient: core.savedObjects.getScopedSavedObjectsClient(rawRequest as any),
	};

Where rawRequest is constructed like @restrry showed.