[k8s driver] network_policies allowlist accepted by gateway but not propagated to proxy ACL (policy_denied)

[bradleyfay]

Summary

In the k8s driver (OpenShell v0.0.73), a SandboxSpec with a network_policies allowlist entry for a specific host:port is accepted by the gateway without error, but exec-stream processes still receive policy_denied when attempting to reach that host via the Squid proxy. The policy is validated and acknowledged by GetSandboxConfig / UpdateConfig, but never translated into a proxy ACL rule.

Environment

• OpenShell gateway: ghcr.io/nvidia/openshell/gateway:0.0.73 (k8s driver)
• OpenShell Python SDK: openshell 0.0.73 (from PyPI)
• Cluster: k3s v1.31 (local)
• Driver: kubernetes

Reproduction

1. Create a sandbox with a network_policies allowlist

from openshell import SandboxClient
from openshell._proto import openshell_pb2 as sb

client = SandboxClient.from_active_cluster()

policy = sb.SandboxPolicy()
rule = sb.NetworkPolicy()
endpoint = sb.NetworkEndpoint(
    host="my-service.my-namespace.svc.cluster.local",
    port=80,
    access="allow",
)
rule.endpoints.append(endpoint)
policy.network_policies["allow-my-service"].CopyFrom(rule)

spec = sb.SandboxSpec(
    template=sb.SandboxTemplate(image="ghcr.io/omnigent-ai/omnigent-host:v0.3.0"),
    policy=policy,
)
ref = client.create(spec=spec)
ready = client.wait_ready(ref.name, timeout_seconds=60)
print(f"Sandbox ready: {ready.name}")

2. Confirm the policy is acknowledged

Gateway logs show:

INFO openshell_server::grpc::policy: GetSandboxConfig served from spec (backfilled version 1)
INFO openshell_server::grpc::policy: UpdateConfig: new policy version persisted  version=2  policy_hash=<hash>

3. Attempt to reach the allowlisted host from exec_stream

for item in client.exec_stream(
    ready.name,
    ["curl", "-s", "http://my-service.my-namespace.svc.cluster.local/health"],
    timeout=10,
):
    print(item)

4. Observed result

{"detail": "GET my-service.my-namespace.svc.cluster.local:80/health not permitted by policy", "error": "policy_denied"}

The proxy returns policy_denied despite the network_policies allowlist entry.

5. Confirmed exec env

Exec-stream processes receive these env vars from the OpenShell supervisor:

HTTP_PROXY=http://10.200.0.1:3128
HTTPS_PROXY=http://10.200.0.1:3128
http_proxy=http://10.200.0.1:3128
https_proxy=http://10.200.0.1:3128
ALL_PROXY=http://10.200.0.1:3128
grpc_proxy=http://10.200.0.1:3128
NO_PROXY=127.0.0.1,localhost,::1

The only default route in the exec namespace is default via 10.200.0.1 (the Squid proxy). All egress goes through the proxy; the allowlisted host is unreachable.

Expected behavior

A network_policies entry with access: allow for a specific host:port should result in the proxy permitting traffic to that destination. The policy is accepted and acknowledged by the gateway — it should be propagated to the proxy ACL.

Additional context

This is related to #787 (TLD wildcard patterns silently rejected by proxy). PR #791 fixed validation for wildcard patterns, but the underlying ACL-propagation gap appears to persist for non-wildcard entries: the gateway validates and persists the policy, but the Squid ACL is never updated regardless of the access value.

We also confirmed via AddAllowRules inspection that this RPC is part of UpdateConfigRequest.merge_operations but is callable only from the sandbox supervisor (not from the control-plane client), so there is no workaround available from the SDK side.

— Gus

[johntmyers]

access="allow" is not valid. Try using "full." Additionally I would also check the sandbox logs for details on the denial as well as check for any pending network rules that are waiting approval. The TUI should show them easily.

I think there is another issue that addresses how the "access" field accepts arbitrary strings which allows invalid policies.

[johntmyers]

#2008