Where the rules live

A rule about a workstation can live inside it, at its edge, or outside it.

Inside the workstation, every rule is advisory. The agent’s settings, its list of allowed tools and the workstation’s own network configuration are all files and processes the agent can edit or stop. The login user has passwordless sudo by default, and a provisioning script in the system phase runs as root even when identity.sudo: false turns sudo off. So a rule you need enforced has to sit somewhere the agent cannot reach.

At the edge of the workstation is the VM boundary, and its job is to protect your machine. A LocalBinding carries the ports you name across that boundary, in either direction, or every port the workstation listens on if you ask for that, and only the owner of your machine can carry one of its services in.

Outside the workstation is where the rules about its reach are held. On a cloud, your cloud’s firewall rule holds the addresses the workstation may reach, and an edge instance, a small VM in your account, holds the host names, on ports 80 and 443. On vz, hcs and qemu, the workstation’s only link out leads to its own network process, or to an edge VM once a namespace administrator declares an Edge for it. Whichever it is, that is what holds the firewall rule, the hostname allowlist, the injected key and the signing key of the certificate authority the workstation trusts. None of them is ever inside the workstation.

Two things follow from that. A strict workstation that no Edge serves yet is held closed rather than left open: on vz, hcs and qemu it reaches nothing, and on a cloud it reaches only what it needs to stay managed and the endpoints of its Integrations. And a list of host names is only as strong as the address-level deny underneath it, because the name is read off the connection. Without that deny, an agent could dial an address directly and go around the list.

Which to choose

Aim for rules held outside the workstation: an egress block with enforcement: strict, a credential injection rule for each key the agent needs, and a Policy or OrgPolicy for the limits a member must not widen. If you do not yet know which destinations to allow, start with audit and let it write the list. That is the configuration that holds against root.

Stopping short of it is a choice, and each stop gives something up:

  • The agent’s own settings, its list of allowed tools and a firewall configured inside the VM cost nothing to set up and are enough for a developer’s own convenience. They are not a control. The login user has sudo and a system script runs as root, so the agent, or anything it runs, can change or remove them.
  • The VM boundary on its own, with no egress block and keys placed inside, protects your machine and nothing else. The workstation shares none of your folders and, on vz and hcs, has no path to your machine’s services, but it reaches anything your network routes, and every process inside can read a key you placed there. That is enough for an experiment that holds no credentials and touches nothing private, and for nothing more.
  • Rules held outside the workstation cost you the list of destinations, which audit can write for you, and on a cloud an Edge if the list names hosts rather than addresses. They cannot be held on lima or wsl2, so run on vz, hcs, qemu or a cloud.

Where to go next

These pages continue from here: