feat(protocol): Introduce 'RemoteRun' target type (Shell, OpenStack, K8s) - #1551

[senolcolak]

Description

Closes #1551

This PR introduces a new protocol module warpgate-protocol-remoterun. The goal is instead of strictly proxying connections to static hosts, Warpgate can now manage ephemeral environments and execute direct remote commands.

This feature adds a new RemoteRun target type with three distinct execution strategies:

1. Shell Execution: Runs a specific command on a remote host (or the gateway itself).
2. OpenStack Ephemeral VM: Provision a fresh VM via OpenStack APIs, injects public keys from GitHub, connects the user, and destroys the VM upon session termination.
3. Kubernetes Ephemeral Pod: Spawns a temporary Pod (e.g., ceph-tools), waits for readiness, attaches the user via kubectl exec, and cleans up the pod afterwards.

Technical Changes

Backend (warpgate-protocol-remoterun & warpgate-common)

• Created new crate warpgate-protocol-remoterun.
• Updated Target and TargetKind structs to support the RemoteRun variant.
• Shell Mode: Implemented standard command execution wrapper.
• OpenStack Mode: Implemented reqwest client to interact with Nova/Compute APIs for server creation and key injection.
• K8s Mode: Integrated kube-rs to handle Pod lifecycle (Create -> Wait -> Exec -> Delete).

Frontend (warpgate-admin)

• Updated the Add/Edit Target modal.
• Added dynamic form logic: Selecting "Remote Run" reveals a sub-type selector (Shell vs. OpenStack vs. K8s).
• Form fields validate dynamically based on the selected strategy (e.g., "Flavor ID" is only visible/required for OpenStack).

Configuration Examples

Users can configure these targets via warpgate.yaml:

1. Shell Execution

targets:
  - name: "raw-ssh-jump"
    kind: RemoteRun
    mode: Shell
    command: "ssh -J user@bastion internal-host"

2. OpenStack Ephemeral VM

targets:
  - name: "dev-sandbox"
    kind: RemoteRun
    mode: OpenStack
    api_url: "https://openstack.example.com:5000/v3"
    auth_token: "secret-token-ref" # Or use Vault reference
    flavor_id: "m1.small"
    image_id: "ubuntu-22.04-LTS"
    network_id: "net-uuid"
    github_username: "developer-account" # Fetches keys from github.com/developer-account.keys

3. Kubernetes Ephemeral Pod (e.g., Ceph Tools)

targets:
  - name: "ceph-admin"
    kind: RemoteRun
    mode: Kubernetes
    kubeconfig: "/etc/warpgate/kubeconfig.yaml"
    namespace: "rook-ceph"
    pod_image: "rook/ceph:master"
    command: "/bin/bash"

[LarsSven]

That's actually an amazing feature, we may also want to use this!

[LarsSven]

@senolcolak I'm curious, how would this work with multiple users on the same target? Would they all log into the same VM/pod, or would each access to a target spin up its own pod/VM?

[senolcolak]

@senolcolak I'm curious, how would this work with multiple users on the same target? Would they all log into the same VM/pod, or would each access to a target spin up its own pod/VM?

Here the goal is to create an ephemeral connection. Each user will trigger a command for a new session.
like you need a temporary access to a Rook/Ceph cluster, for each access a temporary pod will be created

kubectl run -n rook-ceph ceph-tools-temp-session \
  --rm -it \
  --image=$(kubectl get deployment -n rook-ceph rook-ceph-tools -o jsonpath='{.spec.template.spec.containers[0].image}') \
  --restart=Never -- bash

[LarsSven]

Ah okay fair, that's unfortunate. We were mainly looking for something where an ephemeral environment is spun up for a group that is destroyed if no one is in it, but when multiple people connect they all connect to the same ephemeral environment, but your usecase makes sense.

[senolcolak]

Ah okay fair, that's unfortunate. We were mainly looking for something where an ephemeral environment is spun up for a group that is destroyed if no one is in it, but when multiple people connect they all connect to the same ephemeral environment, but your usecase makes sense.

This will be a bit difficult, but still achievable via using openstack integration. This can be implemented as an enhancement to our functionality.

[LarsSven]

@Eugeny is this a feature you would be interested at merging at some point in the future? Because I'd be very interested in this feature

[senolcolak]

@LarsSven I will check this once more, create a more narrowed version. The current version supports too much in a single stack.

[senolcolak]

#1530 solves this