Native unixsock/tcp tunnel between client and platform #266

New issue

Open

opened 2026-06-06 22:22:07 +00:00 by lrvick · 3 comments

lrvick commented

2026-06-06 22:22:07 +00:00

(Migrated from codeberg.org)

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-06 22:23:21 +00:00

(Migrated from codeberg.org)

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

vkobel commented

2026-06-07 10:26:14 +00:00

(Migrated from codeberg.org)

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 10:23:42 +00:00

(Migrated from codeberg.org)

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.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

public/platform#266

No description provided.

Rows
Columns