Relax the ESO UUID-ID requirement for the rules SO

[cnasikas]

Users are using tools like terraform to provision their rules as code, and as such, they need a user-friendly ID when creating rules. This can help will correlating easily with other resources eliminating the need for searching the right ones. At the moment of writing, the Create Rule API supports creating rules with a specified ID but they have to be a UUID. The reason is that the rule SO has encrypted values (the API key of the user that created or updated the rule) and SOs with encrypted values must have IDs as UUID because the IDs are part of the AAD used during encryption and they should be hard to guess. We could introduce functional IDs but there is no way to guarantee the uniqueness of both a functional ID and a technical ID (SO ID). Therefore, it would be nice if we could relax the ESO UUID-ID requirement for the rules SO (alerts).

Related: #182594

The relevant validation is located here:

kibana/packages/core/saved-objects/core-saved-objects-api-server-internal/src/lib/apis/helpers/common.ts

Lines 91 to 118 in b628770

	/**
	* Saved objects with encrypted attributes should have IDs that are hard to guess, especially since IDs are part of the AAD used during
	* encryption, that's why we control them within this function and don't allow consumers to specify their own IDs directly for encryptable
	* types unless overwriting the original document.
	*/
	public getValidId(
	type: string,
	id: string | undefined,
	version: string | undefined,
	overwrite: boolean | undefined
	) {
	if (!this.encryptionExtension?.isEncryptableType(type)) {
	return id || SavedObjectsUtils.generateId();
	}
	if (!id) {
	return SavedObjectsUtils.generateId();
	}
	// only allow a specified ID if we're overwriting an existing ESO with a Version
	// this helps us ensure that the document really was previously created using ESO
	// and not being used to get around the specified ID limitation
	const canSpecifyID = (overwrite && version) || SavedObjectsUtils.isRandomId(id);
	if (!canSpecifyID) {
	throw SavedObjectsErrorHelpers.createBadRequestError(
	'Predefined IDs are not allowed for saved objects with encrypted attributes unless the ID is a UUID.'
	);
	}
	return id;
	}

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[legrego]

@cnasikas thanks for raising this. Can you help us understand the priority of this request, and ideal timeline from your perspective?

[cnasikas]

Hey @legrego! I would say is of medium+ priority and if it can be done for 8.17 it would be great. Any concerns with the suggested timeline?

[legrego]

I would say is of medium+ priority and if it can be done for 8.17 it would be great. Any concerns with the suggested timeline?

@cnasikas At this point, 8.17 sounds reasonable to us, but we can't yet commit to the timeframe. We will let you know if it looks like it'll miss feature freeze.

[SiddharthMantri]

Hi @cnasikas! We've just added a new field for consumers to use to opt-out of random IDs for ESOs in this PR: #198287. You should now be able to register the ESOs and opt-out of the requirement which will allow you to set predictable IDs on the objects.

Let us know if this new option is what's expected for the rules SOs to achieve what the users might need.

[cnasikas]

Thank you so much @SiddharthMantri! I will open a PR soon and let you know.

[cnasikas]

Done #199119! It is working as expected.