I see Goose.ai is gaining traction for self-hosting. Their plugin marketplace is the primary threat surface you're asking about. The core problem is that you're now running a plugin ecosystem designed for a managed service, where the threat model assumed central curation and sandboxing you likely don't have.
Before you touch a config file, answer these questions:
* What is the *actual* business need for the marketplace? Are there specific, vetted plugins you require, or is this a "nice-to-have"?
* Who are your users? Internal devs? The public? Their skill level dictates the blast radius.
* What's the isolation model? Are plugins running in a sandboxed interpreter, in containers, or directly in the main process?
My immediate recommendations, assuming you must run it:
* Disable the marketplace entirely if possible. Manually install and vet the specific plugins you need from source. Treat them as custom code.
* If you must enable it, implement network-level controls. The Goose host should have zero egress to the internet. Marketplace metadata and plugin fetches should be proxied through a scanning service you control.
* Enforce a mandatory code review for any plugin before it's deployed, even "trusted" ones. Look for:
* Arbitrary network calls
* Filesystem access outside a strict temp directory
* Attempts to spawn subprocesses
* Use of eval() or dynamic code loading
* Run plugins under a strict, dedicated OS user with minimal privileges. Use kernel namespaces (cgroups, seccomp-bpf) if you can.
The default configuration is built for convenience, not security. You're not just locking down a feature; you're taking on the role of a platform security team. Start by defining what a "compromised plugin" could do to your data and other services, and work back from there.
If it's not in the threat model, it's not secure.
Right on, user54's questions are the real starting point. I wasted a weekend because I skipped that first one - my "need" was just curiosity, which isn't a need at all. Turned off the whole marketplace and saved myself a headache.
For the isolation model, last I poked at Goose, plugins ran in a pretty lightweight Node sandbox, not containers. That changes the game. If you *do* proxy fetches through a scanner, you're basically building that central curation they assumed you'd have, which is a fun project but a whole new can of worms.
My caveat on disabling egress: watch out for sneaky DNS or fallback to public CDNs in the plugin code itself. I had to firewall at the host level, not just in compose.
Still learning, still breaking things.