Audit logs should have a way to correlate Access Requests from a root cluster to related events on the leaf cluster

[milos-teleport]

Description of the problem

Customers using trusted clusters are not able to deterministically correlate events when creating access requests on the root cluster for the purposes of accessing a leaf cluster. There currently isn't a common "key" between the request access on the root cluster and the related events on the leaf cluster.

A more technical analysis from @fspmarshall :

Based on tracing the path for one of the events that they are seeing in root but not in leaf, I was able to trace the discrepancy down to this remapping logic. This logic builds a fake in-memory tlsca.Identity to represent the local "post-mapping" state of a remote identity. The ActiveRequests field is discarded during the mapping process, and the mapped identity ends up forming the basis of the user metadata that gets included in the event. This may not be the only location where we discard request IDs from remotes, and I'm not certain wether this was something we did deliberately or not.
I can't think of any particular harm tracking access request IDs across the cluster boundary would cause (other than confusing logs if you don't realize the IDs are for remote requests), but it's possible that adding a new field like RemoteActiveRequests or somesuch might be a bit safer, in case there's something we might have missed.

What would you like Teleport to do?

Allow correlation between access request events on the root cluster to related events on the leaf cluster

What problem does this solve?

Allows Teleport customers to create audit reports of Access Requests for trusted clusters

If a workaround exists, please include it.

Right now, time matching seems to be a workaround, but this is a manual process which works for one or two events and does not scale for the purposes of something like creating audit reports.