[Investigate] Kibana audit logging: Capture session expiration

[arisonl]

This is the [investigate] counterpart of #119487 for the case of a "silent" expiration (case 2b in the linked issue).

[elasticmachine]

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

[jportner]

@thomheymann suggested that we could start with logging just the session ID for the "silent" expiration (e.g., the session is cleaned up when the user doesn't have the browser open / hasn't actually taken an action to log out)

@azasypkin mentioned that we use deleteByQuery to clean up sessions:

kibana/x-pack/plugins/security/server/session_management/session_index.ts

Lines 458 to 465 in 2c4e795

	const { body: response } = await this.options.elasticsearchClient.deleteByQuery(
	{
	index: this.indexName,
	refresh: true,
	body: { query: { bool: { should: deleteQueries } } },
	},
	{ ignore: [409, 404] }
	);

I mentioned we could use the _source parameter to determine which sessions were deleted, but even though that is documented, it appears that parameter doesn't actually do anything. I've reached out to the Elasticsearch team to inquire about this, but it seems like it's not a bug, rather an error in the docs. Edit: turns out this is a docs bug, I opened elastic/elasticsearch#80962 to fix it

As a fall-back, we could do a two-step operation (search, then bulk-delete).

[thomheymann]

As a fall-back, we could do a two-step operation (search, then bulk-delete).

When changing deleteByQuery to a two-step operation using search and bulk-delete we should consider a throttling / worker queue mechanism in order to avoid performance issues when this operation is run against large datasets.