Create sandbox event endpoint and handlers

[0div]

Description

We currently do not have a way to send events from inside a sandbox and programmatically handle them from the host, this is an attempt to solve that.

Setup networking in sandbox that routes http://events.e2b.dev requests to a server listening in orchestrator with customizable handlers.

• add internal routing (/etc/hosts) in sandbox
• add ip table rule to route sbx event requests to event server
• validate sandbox request headers to include sandbox_id and team_id
• parametrize event handler registering for event server
• appends events to redis sorted set
• abstract event store interface with getters and setters
• build API routes to fetch events

Test

[infra]
$ make build-and-upload/envd
$ make build-and-upload/template-manager
$ make build-and-upload/orchestrator
$ make plan
$ make apply 

[E2B/template/base]
$ e2b template build

[Sandbox]
$ e2b sbx sp base
user@e2b:~$ curl -X POST http://event.e2b.dev/test -H "E2B_SANDBOX_ID: iws6vifpvohxsdi6anh48" -H "E2B_TEAM_ID: 460355b3-4f64-48f9-9a16-4442817f79f5" -d '{"your": "data"}'

{"event_ack": true, "path": "/test"}

user@e2b:~$ curl -X GET http://event.e2b.dev -H "Content-Type: application/json" -H "E2B_SANDBOX_ID: isjd58fqblghn6ydmd9av" -H "E2B_TEAM_ID: 460355b3-4f64-48f9-9a16-4442817f79f5"

[{"path":"/test","body":{"your": "data"}}]

[linear]

E2B-2486 Create internal sandbox event endpoint

[dobrac]

I don't see proper cleanup for these two

[dobrac]

this can be spoofed by the sandbox, we shouldn't trust anything the sandbox sends us

[0div]

indeed, but when these are used for ad-hoc events defined by users that should be fine, for our internal defined ones, they would be sent via envd which would have access to those via mmds stuff ive been working on. the same could be said about envd server. I'm thinking of maybe redirecting the requests to an envd forward proxy but that could be rerouted too with some effort i think.

[dobrac]

the security concern is that the user sandbox would pretend it's another sandbox ID and team ID -> sending the event to completely different target, potentially with malicious desires

[0div]

it really depends what the handlers do, and if we're to check if the sandbox is running and belongs to the team id that should narrow it down. the same could be said for the potential for mangling the responses from the server running in envd.

[dobrac]

use different IP than 8.8.8.7, I guess any IP from these should be more appropriate:

var blockedRanges = []string{
	"10.0.0.0/8",
	"169.254.0.0/16",
	"192.168.0.0/16",
	"172.16.0.0/12",
}

[0div]

ideally yes, i first tried private IPs, they don't leave the sandbox through the network bridge with current setup, i'd have to figure out a way to route one of the private ones this way.

[dobrac]

just note, these ranges are blocked by default, you need to enable the target IP address (maybe that might be why you haven't seen them routed)

[dobrac]

Also, how will we handle events like sandbox creation, deletion, etc? Basically events emitted from outside of the sandbox

[0div]

Also, how will we handle events like sandbox creation, deletion, etc? Basically events emitted from outside of the sandbox

This is not meant to replace events emitted from outside the sandbox.

[dobrac]

I've meant that we don't have events emitted from the outside, so the question is if it maybe makes sense to have it united

[0div]

I've meant that we don't have events emitted from the outside, so the question is if it maybe makes sense to have it united

any event that can be listened to from the outside should continue to be—especially if it's uncertain the VM is running—any event we would have to poll for inside the sandbox ideally shouldn't.