Ability to specify custom id for alerts and actions

[mikecote]

In certain cases like system generated alerts, you want to

• prevent duplicates alerts from being created (idempotent alert creation)
• be able to update specific rules over time
• import and export rules without having duplicates appear

One suggested approach to doing this is to be able to assign custom IDs to alerts that would be the same in any installation, and prevent duplicates if running an alert setup multiple times.

[elasticmachine]

Pinging @elastic/kibana-stack-services (Team:Stack Services)

[peterschretlen]

@mikecote @FrankHassanabad it looks like this might be possible today, provided you use the alert client? It wouldn't be possible via the API, but looking at the client, you can pass SavedObjectsCreateOptions:

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

Lines 131 to 134 in ce99844

	const createdAlert = await this.savedObjectsClient.create('alert', rawAlert, {
	...options,
	references,
	});

And it looks like the options will allow you to override the ID:

kibana/src/core/server/saved_objects/service/saved_objects_client.ts

Lines 36 to 46 in ce99844

	export interface SavedObjectsCreateOptions extends SavedObjectsBaseOptions {
	/** (not recommended) Specify an id for the document */
	id?: string;
	/** Overwrite existing documents (defaults to false) */
	overwrite?: boolean;
	/** {@inheritDoc SavedObjectsMigrationVersion} */
	migrationVersion?: SavedObjectsMigrationVersion;
	references?: SavedObjectReference[];
	/** The Elasticsearch Refresh setting for this operation */
	refresh?: MutatingOperationRefreshSetting;
	}

[mikecote]

In theory, yes as you can bypass the TypeScript type checks and it would pass along.

The one place that will stop you from doing so is here: https://github.com/elastic/kibana/blob/master/x-pack/plugins/encrypted_saved_objects/server/saved_objects/encrypted_saved_objects_client_wrapper.ts#L58-L60.

On the good side, we're not too far from supporting custom ids as we would just need to revive this PR: #42762.

[mikecote]

A PR merged in the ESO plugin to enable us to do this enhancement.

[mikecote]

I have a PR opened to support this (#89814) with the limitation that the id is UUID v1 or generated by SavedObjectsUtils.generateId().

@spong, this has been requested for the detection rules. Is the limitation of UUID v1 ok with you?

[spong]

I believe that should be fine @mikecote. We currently use UUID v4 for our rule_id's (which was our workaround for maintaining a static id), so we'd need to take that into consideration when migrating, but nothing immediately comes to mind that would be problematic with this limitation. I'll check with the team in our next sync just to be sure though.

[mikecote]

@spong, actually, I think UUID v4 will work as well. It validates ok here: https://github.com/elastic/kibana/blob/master/src/core/server/saved_objects/service/lib/utils.ts#L78. But it's good to know UUIDs work for you 👍 I wanted to make sure your requirement didn't need to work with string / readable names.