Network for scripts

Scripts often need the network: a CSV on a file share, a report service in the plant network, an endpoint on the internet. Where they may connect is set once for all scripts of the installation, with the button Scripts: … at the top right of the scripts page (it names the current choice). Only administrators can change it, and every change is recorded in the audit trail.

The three settings

• Network open – the default. Scripts may connect anywhere except to the installation itself.
• Only these targets – scripts may connect only to what is listed. One target per line: a host name (fileserver.example.local), an address (10.20.1.5) or a range (10.20.0.0/16), optionally with a port (fileserver.example.local:445). Without a port, every port of that target is allowed. Names are looked up each time a script runs, so a server that moves is followed.
• No network – scripts cannot connect anywhere, and cannot even look up a name.

What is never reachable

Whatever is chosen, a script never reaches the installation’s own database, its other services, other containers next to it, the server it runs on (its public addresses and its loopback 127.0.0.1) or a cloud metadata service (169.254.169.254). This is checked by address, not by name: a name that points at one of these addresses is refused just the same.

On a hosted installation, private networks (10.x, 172.16–31.x, 192.168.x, 100.64.x) are refused as well – a hosted installation has no plant network of its own, so such an address can only belong to the hosting, and it must stay apart from the other installations sharing the pool. On an installation in the plant, the plant network is reachable as the setting says.

A listed target that can never be reached is named when the setting is saved.

Seeing what a script connected to

Every connection a script makes – target, port, allowed or refused and why – appears as a line in the diagnostics panel, as the script reported it. A refused connection also fails in the script itself, with the reason in the error message, on the line that made it.

Two honest limits of that line. First, it is written from inside the script’s own process, so a determined script could word it differently – trust the refusal, not the prose. Second, a script that reaches the network another way (a C call, a child program) is still blocked by the barrier below it, but that attempt does not show up as a line. And with Only these targets, looking a name up (DNS to the installation’s resolver) stays possible even though connecting to an unlisted target does not – otherwise no name could be used at all.

If the dialog says scripts run without a user of their own or without the network barrier, this installation could not set the protection up fully (typically a developer machine). Only the check inside the Python process applies then; the diagnostics panel says the same at start. On a hosted pool a script is refused outright rather than run without that barrier.