Encrypted saved objects plugin to allow specifying a custom id on create

[mikecote]

Use case (short version)

Making task manager use encrypted saved objects would need to keep the functionality of specifying ids when scheduling tasks.

Use case (long version)

Alerts will soon contain API keys to allow executing requests on behalf of the user. When the alert fires actions, those actions also need to execute requests on behalf of the creator of the alert and not the creator of the action. Task manager sits between alerts and actions to handle scaling and error handling.

In order to have alerts pass the API key to an action, I was thinking of storing them within the task. We could convert task saved object type to use encrypted saved objects (ESO) and encrypt a specific attribute. One feature missing in ESO is the ability to specify ids on create. Task manager supports this and isn't something that can be rolled back.

[elasticmachine]

Pinging @elastic/kibana-security

[kobelb]

Is task manager using a UUID as the ID currently?

[mikecote]

@kobelb it's now using whatever the saved objects client is providing to generate ids (when an id is not provided).

[kobelb]

@kobelb it's now using whatever the saved objects client is providing to generate ids (when an id is not provided).

I'm confused. If you're using the SavedObjectsClient itself to generate IDs, why can't the ESO specify the ID?

[mikecote]

Everything with ESO works fine when using generated IDs. When providing custom ids (since task manager supports both) ESO throws an error here https://github.com/elastic/kibana/blob/master/x-pack/legacy/plugins/encrypted_saved_objects/server/lib/encrypted_saved_objects_client_wrapper.ts#L56-L58.

[kobelb]

When task manager specifies an ID, is it always a UUID?

[mikecote]

Most of the time it will be a reserved word, something like Maps-${TELEMETRY_TASK_TYPE} https://github.com/elastic/kibana/blob/master/x-pack/legacy/plugins/maps/server/maps_telemetry/telemetry_task.js#L11. This allows to reference a scheduled task programatically at a future time, avoid duplication in scheduling, etc.

[kobelb]

Most of the time it will be a reserved word, something like Maps-${TELEMETRY_TASK_TYPE} https://github.com/elastic/kibana/blob/master/x-pack/legacy/plugins/maps/server/maps_telemetry/telemetry_task.js#L11. This allows to reference a scheduled task programatically at a future time, avoid duplication in scheduling, etc.

Thanks. I was hoping we could validate that the provided ID was a UUID v4, but it sounds like to support your use-case we'd need to allow any arbitrary ID.

[mikecote]

Correct, they can be anything the developer wants (in task manager's case).