@Eugeny is this feature still planned? Since we are very interested in it we would love to know the status of the feature

It's already mostly functional in this branch, however I haven't had time to polish and finalize it yet

Quality Gate failed

Failed conditions
3.1% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

@Eugeny the WebSocket handler for kubectl exec/attach/port-forward is incomplete and doesn't record sessions. Why not use a jail/sidecar approach instead? Instead of implementing WebSocket recording here, we could:

1. Deploy a lightweight container/pod with kubectl + SSH server (we lose single binary, but maybe it will be an addon for the extra feature)
2. Configure it as a regular SSH target in Warpgate
3. Users SSH into it and run kubectl commands
4. Terminal I/O is automatically recorded via existing SSH recording infrastructure

Pros:

• Reuses existing SSH terminal recording (TerminalRecorder)
• Full session replay works out of the box
• Avoids complex WebSocket stream recording
• Leverages existing SSH session management, auth, etc.
• Simpler to maintain

The current approach requires implementing WebSocket recording from scratch, which is complex and error-prone. The jail approach reuses existing, tested code.

If we stick with the WebSocket approach, we'd need to:

• Authenticate user and create session in the WebSocket handler
• Start KubernetesRecorder for WebSocket streams
• Connect WebSocket to Kubernetes API
• Forward messages bidirectionally while recording stdin/stdout/stderr

This is my (and probably more people)'s last missing feature towards switching from Teleport.

wdyt?

@thereisnotime that would defeat the core concept of not needing special handling on the client side (now you need to SSH and run kubectl manually instead of having a k8s API endpoint). And it won't work with management tools that expect to be able to connect to the API directly (Lens etc).

I'll implement websocket forwarding directly - though the initial release of the k8s support might not include exec session recordings

@thereisnotime that would defeat the core concept of not needing special handling on the client side (now you need to SSH and run kubectl manually instead of having a k8s API endpoint). And it won't work with management tools that expect to be able to connect to the API directly (Lens etc).

I'll implement websocket forwarding directly - though the initial release of the k8s support might not include exec session recordings

That makes sense. What about a hybrid approach - when exec is being done then switch to standard recording and a command option? It might break standard exec client integrations but it will be really closer to replacing https://goteleport.com/docs/reference/architecture/session-recording/#kubernetes-sessions

I am speaking as a user and as somebody who makes the decisions for security tooling for companies, from my perspective recording would be more beneficial than full 100% compliance with one command as most internal attacks in prod environments are done via exec.

What do you think?

I've implemented full support for recording exec and attach streams (for the current v5 websocket channel protocol, not the legacy SPDY based protocol) - would appreciate if you could give it a try!

Quality Gate passed

Issues
9 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
2.4% Duplication on New Code

See analysis details on SonarQube Cloud