Kubernetes target support

[Eugeny]

Closes #1036

[LarsSven]

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

[Eugeny]

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

[sonarqubecloud]

Quality Gate failed

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

See analysis details on SonarQube Cloud

[thereisnotime]

@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?

[Eugeny]

@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]

@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?