[Improvement]: Security: Remote builds can reach AWS EC2 IMDS #1051

Existing issue

• I have searched the existing issues and found no duplicate.

Current behavior

Current behaviour

I could not find any type of isolation around the network egress of remote/server builds beyond the default isolation provided by Docker/BuildKit itself.

OpenShip exposes remote/server builds as a normal deployment option: the build can run directly on the target server instead of on the operator's machine. In that mode, Dockerfile RUN instructions execute through the Docker/BuildKit runtime of the managed host.

By default, docker buildx build runs RUN instructions with the default network mode. That provides network access to the build sandbox. Docker/BuildKit's default build networking does not provide a metadata-specific deny policy to block link-local cloud metadata endpoints such as 169.254.169.254 by default.

I created a small, non-destructive lab reproducing this behavior without contacting a real cloud metadata service:

https://github.com/memparanoid/buildkit-imds-reachability-lab

The lab places a mock metadata service at the same link-local address used by common cloud metadata services and shows that a default BuildKit/Buildx RUN can reach it. No real cloud credentials are requested or exposed. Instructions to run the lab can be found at the README.md file at the root of the repository.

Reachability

This matters because 169.254.169.254 is used by several major providers for instance metadata, including AWS EC2 IMDS, Azure IMDS, Google Cloud metadata, Oracle Cloud Infrastructure metadata, DigitalOcean metadata, and others.

Depending on the provider and instance configuration, metadata services may expose identity tokens, instance credentials, managed-identity tokens, user data, or other sensitive instance information.

Boundary

The security boundary therefore currently appears to be:

untrusted repository / Dockerfile
→ remote build on managed server
→ Dockerfile RUN
→ default BuildKit network
→ network position of the managed host
→ potentially reachable metadata service

Scope

This does not require a deliberately malicious base image or an ONBUILD RUN instruction.

Any normal build step that executes third-party code inherits the same network reachability. For example, a Dockerfile containing RUN npm install, RUN pip install, RUN cargo build, RUN apk add, or RUN apt-get install may execute package lifecycle scripts, build scripts, installation hooks, or other dependency-controlled code during the build.

If one of those dependencies is compromised or malicious, it can attempt to reach the metadata endpoint from inside an otherwise ordinary-looking build.

So the risk is broader than intentionally malicious Dockerfiles: it also includes supply-chain compromise in dependencies executed during normal remote builds.

--network=none prevents this, but it is not a practical global fix because many normal Dockerfiles require network access during build for package managers, dependency downloads, Git, registries, etc.

Proposed improvement

A relatively conservative mitigation would be to run remote Buildx builders on a dedicated, predictable subnet and block cloud metadata traffic from that subnet at the host firewall.

For example:

1. OpenShip uses a fixed build subnet such as 172.31.250.0/24.
2. Remote builders are required to use that network.
3. During server setup, the operator installs a root-owned rule such as:
   iptables -I DOCKER-USER -s 172.31.250.0/24 -d 169.254.169.254/32 -j REJECT
4. OpenShip verifies that the rule is present before allowing remote builds.

This likely requires a one-time privileged provisioning step, since the regular OpenShip SSH user only needs enough privilege to operate containers, while firewall configuration normally requires root.

The same mechanism could later be extended into a broader build-egress policy for link-local, private/LAN ranges, host services, IPv6, and explicit allow-list exceptions.

Benefits

This would preserve remote builds while better protecting users' private infrastructure data and cloud credentials.

In particular, it would prevent ordinary build steps and compromised dependencies from reaching instance metadata services that may expose temporary credentials, identity tokens, user data, or other sensitive information tied to the managed host.

Users would no longer need to rely on provider-specific IMDS hardening to keep build-time code away from sensitive cloud metadata.

Additional context

No response