Native unixsock/tcp tunnel between client and platform #266

lrvick commented 2026年06月07日 00:22:07 +02:00

We effectively need:
server( proxy:8080 <-vsock-> enclave(app:unix.sock) <-tcp:8080-> client( tcp -> app:unix.sock)

Also caution CLI should be able to run as a daemon on the client side, and perform health checks based on connectivity to the remote socket or tcp connection it is forwarding. Should function very much like tcp+socket forwarding in ssh.

Then a user can run mysql, nginx, postgres etc in an enclave with a minimal library kernel, no idea what a network stack is, that just listens on a unix socket, and users can plumb that socket securely with end to end encryption to k8s or anywhere else they need comms to that enclave daemon.

IMO this unlocks a ton of use cases, and lets us eliminate a lot of attack surface in the process, as exposing tcp ports to the outside world is the wrong call for most internal use services. Unix sockets tunneled point to point between secure environments without having to care about firewalls, however, is super useful.

We effectively need: server( proxy:8080 <-vsock-> enclave(app:unix.sock) <-tcp:8080-> client( tcp -> app:unix.sock) Also caution CLI should be able to run as a daemon on the client side, and perform health checks based on connectivity to the remote socket or tcp connection it is forwarding. Should function very much like tcp+socket forwarding in ssh. Then a user can run mysql, nginx, postgres etc in an enclave with a minimal library kernel, no idea what a network stack is, that just listens on a unix socket, and users can plumb that socket securely with end to end encryption to k8s or anywhere else they need comms to that enclave daemon. IMO this unlocks a ton of use cases, and lets us eliminate a lot of attack surface in the process, as exposing tcp ports to the outside world is the wrong call for most internal use services. Unix sockets tunneled point to point between secure environments without having to care about firewalls, however, is super useful.

lrvick commented 2026年06月07日 00:23:21 +02:00

Prior art reference: https://github.com/tkhq/qos/blob/main/src/qos_enclave/src/main.rs

Prior art reference: https://github.com/tkhq/qos/blob/main/src/qos_enclave/src/main.rs

vkobel commented 2026年06月07日 12:26:14 +02:00

Yes, 100% needed. Should it leverage Steve? The steve-sdk rust client could be embedded in the caution verify CLI I guess.

However today steve is request/response based, it doesn't fit a raw unix/tcp byte stream (postgres/mysql are stateful), so a streaming data plane is required before this works

Yes, 100% needed. Should it leverage Steve? The steve-sdk rust client could be embedded in the caution verify CLI I guess. However today steve is request/response based, it doesn't fit a raw unix/tcp byte stream (postgres/mysql are stateful), so a streaming data plane is required before this works

ryansquared commented 2026年06月29日 12:23:42 +02:00

that just listens on a unix socket

or vsock, and it leverages existing port binding mechanisms.

I need a proper network flow diagram to understand how this works. Random arrows pointing in various directions is insufficient and does not reveal what's not provided by vsock and socat.

> that just listens on a unix socket or vsock, and it leverages existing port binding mechanisms. I need a proper network flow diagram to understand how this works. Random arrows pointing in various directions is insufficient and does not reveal what's not provided by vsock and socat.