Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow arbitrary plugins on Cloud #6855

Closed
4 tasks
Twixes opened this issue Jun 2, 2021 · 5 comments
Closed
4 tasks

Allow arbitrary plugins on Cloud #6855

Twixes opened this issue Jun 2, 2021 · 5 comments
Labels

Comments

@Twixes
Copy link
Collaborator

Twixes commented Jun 2, 2021

A while ago we released Plugins for PostHog Cloud users.
However the limitation there is that only verified plugins from the official plugins repository are allowed for most users – system safety reasons prevent us from allowing arbitrary code in the multi-tenant architecture.
This is already very useful, but it would still be fantastic and even more powerful if ANYONE could run ANY plugin code (using the source code editor for instance).

Theoretically we could allow it right now, it's practically a single switch. However there's a few issues that we need to sort out beforehand to ensure stability of the system:

In CPU and memory usage protections we're severely limited by using vm2 for running plugins, which is a wrapper over Node's vm module. That's performant and convenient – this way all of the server is Node – but it also makes management of resources difficult in a multi-tenant system. All vm VMs runs inside the same Node process as the rest of the plugin server, so they all share the same pool of process resources.
Cloudflare Workers for example use V8 Isolates more directly, running their own V8-based runtime alternative to Node. That gives them full oversight over activity of each individual worker, at the cost of lots of development effort.
A Node-based alternative to vm2 could be isolated-vm, which seems to offer better isolation characteristics. AFAIK @mariusandra may have some more context on that package.
In any case, a rework of plugin VMs could be really useful, but would also require careful consideration, so a last resort for now.

Extra reading: PostHog/plugin-server#227 on isolation between Cloud tenants.

@mariusandra
Copy link
Collaborator

The additional context here is that the in the first version I actually used isolated-vm instead of vm2 for exactly these reasons. However I dropped it because it made passing objects into the VM absolutely mental. At the end of the day, I would have had to implement some Proxying code similar to vm2, just to get fetch working, and decided it's not worth the effort, considering the time budget and the extremely likely case that I'll leave in some security holes.

@mariusandra
Copy link
Collaborator

mariusandra commented Jun 3, 2021

isolated-vm also runs every vm inside it's own worker/thread. That has scalability implications. The number of VMs is virtually limitless, but the number of threads a server can run, even if massively overprovisioned, is more limited. 32k or so.

Definitely worth investigating deeper though.

@yakkomajuri
Copy link
Collaborator

Another issue to consider is abusing the cache and storage.

@tiina303 tiina303 transferred this issue from PostHog/plugin-server Nov 3, 2021
@posthog-bot
Copy link
Contributor

This issue hasn't seen activity in two years! If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.

@posthog-bot
Copy link
Contributor

This issue was closed due to lack of activity. Feel free to reopen if it's still relevant.

@posthog-bot posthog-bot closed this as not planned Won't fix, can't repro, duplicate, stale Nov 20, 2023
Extensibility automation moved this from Ideas to Done This Sprint Nov 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Extensibility
Done This Sprint
Development

No branches or pull requests

4 participants