Skip to content

Omit sudo from generated lock.yml when network-isolation sandbox is enabled #41267

Description

@lpcox

Summary

When the AWF network-isolation sandbox option is enabled (sandbox.agent.network-isolation: true), the compiler still emits sudo in the generated .lock.yml for the awf binary install and the awf invocation. In network-isolation mode, AWF no longer needs NET_ADMIN/host-iptables egress enforcement, so it can run rootless — a key requirement for ARC (Actions Runner Controller) Kubernetes runners where passwordless sudo/host-iptables are often unavailable.

The compiler should omit sudo from the generated lock when network-isolation is enabled.

Current behavior

For a workflow with sandbox.agent.network-isolation: true, the generated lock contains (line numbers from a real compile):

# Install awf binary
sudo tee /usr/local/bin/awf > /dev/null <<EOF
...
sudo chmod +x /usr/local/bin/awf

# Run awf
sudo -E awf --config ... --build-local -- /bin/bash -c '...'

Desired behavior

When network-isolation is enabled, emit the same steps without sudo (and without -E, since the env is already exported in the step):

tee /usr/local/bin/awf > /dev/null <<EOF
...
chmod +x /usr/local/bin/awf

awf --config ... --build-local -- /bin/bash -c '...'

The artifact-upload permission-fix step (sudo chmod -R a+rX /tmp/gh-aw/sandbox/firewall …) can remain, or ideally also be dropped/guarded since rootless runs no longer create root-owned files.

Evidence (validated rootless)

Manually editing the generated lock to remove sudo from the install + awf invocation (keeping only the artifact-upload sudo) and re-running the network-isolation smoke workflow passes end-to-end without root:

  • awf --config … runs without sudo
  • Local binary install (tee /usr/local/bin/awf, no sudo) succeeds
  • Egress enforcement intact: allowed domain → allowed=200; non-allowed example.com blocked with CONNECT tunnel failed, response 403
  • Firewall summary: 15 requests, 12 allowed, 3 blocked

Reference (gh-aw-firewall): PR github/gh-aw-firewall#5495 and passing rootless run https://github.com/github/gh-aw-firewall/actions/runs/28114712549

Notes / edge cases

  • Without sudo, a benign cleanup warning can appear because container-created files under the chroot-home are root-owned:
    [WARN] Failed to clean up temporary files: EACCES, Permission denied: /tmp/awf-...-chroot-home
    Worth handling (e.g. rootless cleanup, or running the container with the host UID) so the warning disappears.
  • The awf invocation still launches Docker/compose; this requires the runner user to be in the docker group (true for GitHub-hosted runners and standard ARC DinD setups).
  • This should be gated strictly on the network-isolation option — the legacy host-iptables topology still needs sudo.

Acceptance criteria

  • With sandbox.agent.network-isolation: true, the generated .lock.yml contains no sudo for the awf binary install or the awf invocation.
  • Legacy (non-isolation) topology is unchanged (still uses sudo).
  • A compiled network-isolation workflow runs successfully on a rootless/ARC-style runner.

Additional ask: bump default firewall + mcpg container versions to latest

Alongside the sudo change, please bump the default pinned container versions the compiler uses to the current latest releases:

  • Firewall (ghcr.io/github/gh-aw-firewall/{agent,api-proxy,squid}): v0.27.10
  • MCP gateway (ghcr.io/github/gh-aw-mcpg): v0.3.30

These are the latest published releases (both verified resolvable on GHCR) and contain the network-isolation topology egress model. Updating the gh-aw defaults means workflows that don't explicitly pin sandbox.agent.version / sandbox.mcp.version pick up the topology-capable images automatically.

Acceptance criteria (versions)

  • Default firewall container version bumped to v0.27.10.
  • Default mcpg container version bumped to v0.3.30.
  • Recompiled lock files reference the new tags.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions