[Alerting] event log should authenticate actions/alerts with their clients

[pmuellr]

previous title: event log can't find events for preconfigured actions

Because the event log "find" functionality requires a saved object type/id to query over, and it validates the user can read this saved object, it's not possible to "find" event documents for preconfigured actions, since they aren't represented with real backing saved objects.

I know there are some ways of "hooking" saved objects APIs, and so am wondering if there's a possibility for us to provide a hook that would allow preconfigured objects to be "found" via the existing saved object client. I guessing this isn't possible, and it could have other ramifications if it was.

A possible fix for this, just within the event log code, could be to allow some kind of special "hook" for the event log plugin, where a plugin can add a type handler to be called during event log find, to run an additional validation after the SO validation, if it fails, which would allow preconfigured actions to be considered "findable".

Turns out we need this anyway, once we have RBAC enabled - to authenticate actions and alerts via their respective clients to get that RBAC goodness - otherwise we're bypassing security.

The relevant code is here:

kibana/x-pack/plugins/event_log/server/event_log_client.ts

Lines 72 to 85 in 8f7bb05

	async findEventsBySavedObject(
	type: string,
	id: string,
	options?: Partial<FindOptionsType>
	): Promise<QueryEventsBySavedObjectResult> {
	// verify the user has the required permissions to view this saved object
	await this.savedObjectsClient.get(type, id);
	return await this.esContext.esAdapter.queryEventsBySavedObject(
	this.esContext.esNames.alias,
	type,
	id,
	findOptionsSchema.validate(options ?? {})
	);
	}

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[mikecote]

A solution for this will require something similar to what will be needed for feature controls where we can't rely directly on the saved objects client to throw an error when access is unauthorized.

A possible solution would be to have a registry exposed by the event log that the alerting and action plugins can register custom authorization handling for specific saved object types. This will allow to use custom logic (to be developed by #43994 and possibly #63496 based on testing results) in the alerts client and actions client to do custom authorization checks before hitting the unsecured saved objects client.

[pmuellr]

I had the same thought. This might also solve the "problem" with Task Manager saved objects. We could allow the "hook" to do the look up, instead of the event log, as it would know what index to find the relevant SO in. We already require event log clients to register a unique provider value, so shouldn't be hard to extend that registration to allow for "access hooks" or something.

[mikecote]

Marking as blocked until #70395 and #67157 are merged.