capnspacehook
commented
4 months ago This is still an issue in v16. Additionally, if both clusters are set to record at the proxy, a session recording will be present on both clusters but only playable on the root cluster. An entry is present on the leaf cluster but attempting to play it results in nothing happening.
Expected behavior: If the root cluster is set to record at the proxy and the leaf cluster is set to record at the node and a leaf node is dialed from a client connected to the root cluster, one session recording will be recorded by the root cluster.
Current behavior: If the root cluster is set to record at the proxy and the leaf cluster is set to record at the node and a leaf node is dialed from a client connected to the root cluster, duplicate session recordings will be recorded on both clusters.
Bug details:
This is because the root cluster forwards and records the connection at the proxy, and when the leaf node receives the SSH connection it checks the leaf cluster's session recording config. Because it's recording at the proxy, the leaf node also records the session.
We need some way to let leaf nodes know when the root proxy is already recording the session, an idea I had was to have the root cluster send a new
proxy-is-recording@goteleport.comSSH request immediately after the SSH connection is established. The leaf node would handle the request by not recording the session despite what the leaf cluster's session recording config is.To prevent clients sending the
proxy-is-recording@goteleport.comrequest before creating a session and stopping sessions from being recorded, some measures could be put in place:proxy-is-recording@goteleport.comrequests. Legitimate requests will be sent by the forwarding SSH server itself and thus be unimpeded.proxy-is-recording@goteleport.comwould be random data signed by the node cluster's User CA. Upon receiving requests nodes would verify the request was from a Teleport Proxy by verifying the signature of the request payload.