Skip to content

fix: Port code executor container and pod isolation defaults to v1 - #6807

Open
GWeale wants to merge 2 commits into
v1from
backport-v1-pr18
Open

fix: Port code executor container and pod isolation defaults to v1#6807
GWeale wants to merge 2 commits into
v1from
backport-v1-pr18

Conversation

@GWeale

@GWeale GWeale commented Aug 18, 2026

Copy link
Copy Markdown
Collaborator

This PR ports two code executor fixes to the v1 branch:

  1. Container run settings (0a9ce0f6)

    • Behaviour change: ContainerCodeExecutor runs its container with networking disabled, so executed code that makes an HTTP request, resolves DNS, or installs a package fails.
    • Opt out with ContainerCodeExecutor(image="...", network_enabled=True).
    • The container also runs with cap_drop=['ALL'] and the no-new-privileges option.
    • Adds docker>=7 to the test extra.
  2. Pod spec settings (82078801)

    • Behaviour change: the pod GkeCodeExecutor creates sets automount_service_account_token=False, so executed code has no in-cluster Kubernetes API access.

GWeale added 2 commits August 18, 2026 17:22
Ports upstream commit 8207880 to the v1 branch.

The pod that GkeCodeExecutor creates to run model-generated code did not
set automount_service_account_token, and Kubernetes defaults it to true,
so the pod received a token for the namespace's default ServiceAccount.
Code executed in the sandbox could use it to call the cluster's API
server. The pod spec now sets automount_service_account_token=False, so
no token is projected into the pod.

Behaviour change: executed code that today calls the Kubernetes API from
inside the cluster loses that access. Nothing in ADK does this.
Ports upstream commit 0a9ce0f to the v1 branch.

ContainerCodeExecutor started its container with default Docker
networking and no capability restrictions, so the model-generated code
it runs could reach the network, acquire Linux capabilities, and gain
privileges through setuid binaries. Every other ADK code executor is
isolated: GkeCodeExecutor runs under gVisor with all capabilities
dropped, and the Vertex AI and Agent Engine executors run in managed
server-side sandboxes.

The container now starts with networking disabled, all Linux
capabilities dropped, and no-new-privileges set. A new network_enabled
field re-enables networking when the executed code is trusted.

Breaking change: executed code no longer has network access by default,
so anything that makes an HTTP request, resolves DNS, or installs a
package fails until the executor is constructed as
ContainerCodeExecutor(..., network_enabled=True). Dropping capabilities
and setting no-new-privileges do not affect ordinary Python execution.

Also adds docker>=7 to the test extra so that extra installs on its own.
@GWeale GWeale changed the title fix: Port code executor sandbox hardening to v1 fix: Port code executor container and pod isolation defaults to v1 Aug 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants