With github.com/archestra-ai/archestra/pull/6488 was the intention on this to hard block all access to the following ranges from MCP pods with no way to override if the environments networkPolicy is set to unrestricted (Allow All)?:

- 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 - RFC 1918 private ranges (cluster pods, services, nodes) <--- This is the primary one I'm wondering about

- 169.254.0.0/16 - Link-local / cloud metadata endpoints (AWS IMDSv1, GCP, Azure)

- 100.64.0.0/10 - Carrier-grade NAT (RFC 6598)

-- 127.0.0.0/8 - Loopback

-- 0.0.0.0/32 - Treated as localhost by some HTTP libraries

hey 👋

yes, it's intentional - "unrestricted" != "allow all".. it's an always-on-SSRF-floor (DNS + public internet, with RFC1918/link-local/metadata/CGNAT/loopback carved out), and there's no per-environment override for it.

if an MCP server (or Agent's sandbox) genuinely needs a cluster-internal or private-range target, set that environment to "restricted" and list the CIDR explicitly (allowed CIDRs aren't filtered against those ranges, so 10.x/8 and friends work there). the floor only applies on the unrestricted path.

does that make sense?

(our docs were a bit lacking around these details, updated that - thanks for raising this)

Hmmm. Would it be better to rename it to something like internet only or a label is a bit more obvious at a glance without having to get into doco?

The challenge I ran into is I have MCP servers that we create for internal tools that only need to access the internal networks, but not internet, and other ones that need to access resources on the internet.

There's no clean way to limit container access without multiple environments, and if code execution/sandbox is enabled, from what i can see that spins up a new dagger instance per environment always? If that's correct, I pay a 6gb ram/50gb disk penalty to manage MCP container access per environment to manage it in the archestra ui.

I'm currently working around by using a large list of ranges in the default environment that cover all of the internet, and the internal ips I want. But it means all my MCP servers have access to both.

what internal network IPs are you trying to access exactly? cluster DNS is explicitly allowed - are you getting blocked for particular network calls, if so do you have an example one?

I have some internal services I host on subnet 10.1.2.0/ 24

So an MCP server inside archestra can't access that subnet, and the internet, unless I add in a very large list of subnets in the mode that allows you to specify (forgot the name of it)

I don't mind, as there's a workaround. I'd just be sad if that workaround went away

currently the intention with Environments is to give Archestra admins a way to setup a "sandbox" like space for folks to play around + a production environment. For example:

• dev/sandbox - egress policy restricts hitting *.prod.mycompany.com (users can deploy MCPs + have Agents run commands, but restricted from hitting prod APIs)

• prod - could configure this as a "restricted" environment (ex. requires admin approval / some internal governance/approval process)

so you may not need to use Environments.

I'm going to make some small changes in the next version (v1.3.47) - clarifying some of the terminology, but also giving an "escape hatch" for the default environment.

You'll be able to configure "Additional allowed CIDRs" when Egress is set to "Public Internet" (currently we don't allow this) and you'll just need to put 10.1.2.0/24 in there - I think this will be much simpler to maintain then you're workaround 😅

Yeah would be much nicer thqnk you!

(and in this case ☝️ you will still just have the "default" environment, so you won't need to worry about an additional managed-dagger)

btw v1.3.47 is available which contains some improvements around this - upgrade and let me know how this works out for you

Changed over to this now and its working great