[Event log] Use Alerts client & Actions client when fetching these types of SOs

[gmmorris]

Summary

Introduces a pluggable API to Event Log which allows custom Providers for Saved Objects which is used to ensure a user is authorised to get the Saved Object referenced in the Event Log whenever the find api is called.

closes #63961

Dev Notes

The EventLog Setup contract now exposes a registerSavedObjectProvider method which can be used to register a Saved Object provider

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

Lines 37 to 46 in 2d63a67

	export interface IEventLogService {
	isEnabled(): boolean;
	isLoggingEntries(): boolean;
	isIndexingEntries(): boolean;
	registerProviderActions(provider: string, actions: string[]): void;
	isProviderActionRegistered(provider: string, action: string): boolean;
	getProviderActions(): Map<string, Set<string>>;
	registerSavedObjectProvider(type: string, provider: SavedObjectProvider): void;
	getLogger(properties: IEvent): IEventLogger;
	}

This API is used by specifying the Saved Object type and a "provider" callback which is called whenever a new request has come in which is asking for that type of Saved Object.

For example, below you can see a provider for the alert SavedObject type, which creates a new AlertsClient for the request and returns a getter which will attempt to get the SavedObject by its id.

eventLogService.registerSavedObjectProvider('alert', (request: KibanaRequest) => {
    const client = getAlertsClientWithRequest(request);
    return (type: string, id: string) => client.get({ id });
});

The EventLog maintains a registry of each provider, and creates a getter on demand when the user actually requests an object of a certain type, meaning that an AlertsClient will only be instantiated if, and when, the user requests to the events that reference an Alert. Once a getter is created for a specific request it is cached for the remainder of the lifecycle of that request which means a single provider will be used for multiple gets made by the request.

Checklist

Delete any items that are not applicable to this PR.

• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

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

[gmmorris]

@elasticmachine merge upstream

[gmmorris]

@elasticmachine merge upstream

[gmmorris]

@elasticmachine merge upstream

[pmuellr]

LGTM; made a few comments; nice implementation!

[mikecote]

Changes LGTM! Pulled down locally and can confirm the APIs stop working when the user loses access to the alert or connector.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 43b0f2c

Build metrics

✅ unchanged

History

• 💚 Build #65991 succeeded 8d10f0e
• 💚 Build #65497 succeeded dcb7a21
• 💚 Build #64657 succeeded 0ef59c3
• 💔 Build #64646 failed 002b029
• 💔 Build #64291 failed 2d63a67

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