Add session_type and format to session.recording.access audit event event

[gabrielcorado]

This is part of adding usage metrics for session recording access. This PR adds the fields format and session_type to the audit event. Possible values for format are json, yaml, text, and pty.

• The session_type value comes from the access checker, which lists the last audit event from the recording to ensure the user can access the recording type. We had to update the actionForKindSession function to return this type based on the last recording event type.
• format is set by the clients (if applicable) using the gRPC context value. The context was used instead of adding an additional value to the function call because it is only used to enhance the audit event and is not used in the streaming process. This simplifies the usage and avoids increasing the complexity of the streaming functions for metadata values.

Changelog: Include the format (indicates which format the session was accessed in) and session_type (represents the type of the recording, for example, ssh) fields for the session.recording.access audit event.

Example of audit event

{
  "cluster_name": "root.teleport.dev",
  "code": "T2012I",
  "ei": 0,
  "event": "session.recording.access",
  "format": "pty",
  "session_type": "ssh",
  "sid": "a395e5cd-f43a-4891-84d0-cc12efb85662",
  "time": "2024-10-08T05:06:07.713Z",
  "uid": "c4cefd6d-8ba4-48f1-aadf-93b1465cd49a",
  "user": "alice",
  "user_kind": 1
}

[strideynet]

Is this related to a ticket ? I'm curious on the background around this task, I'm somewhat concerned about how we present information in the audit log that can be potentially spoofed by an attacker.

[greedy52]

Is this related to a ticket ? I'm curious on the background around this task, I'm somewhat concerned about how we present information in the audit log that can be potentially spoofed by an attacker.

https://github.com/gravitational/teleport/blob/master/rfd/0171-database-session-playback.md

Postgres PTY playback can be done through web or tsh play. For the web playback, player is run on Proxy. But you are right that for tsh, the format can be spoofed.

The event is mainly used to collect the usage/adoption data of this feature. To me, collecting the format is similar to collecting user agents, where it can be spoofed but it is not critical to the event itself and patterns can be collected even if there is an attacker.

If we really want to prevent spoofing though, some redesign of the backend api may be needed.

[gabrielcorado]

This is the same idea as the access_through from the Teleport Connect use event, where we want to understand which format users are consuming their sessions recordings.

However, the value was added to the audit event as it was already available as always-present data when users access their recordings (which then are converted into prehog events). This is similar to user-agent reporting (as @greedy52 said), which is also present in the audit events (for example, on login events). We could take advantage of knowing the possible values and validate them (avoiding custom values), but it may not make it better (in terms of security).