fix(sandbox): egress-guard init uses sandbox image (has iptables), not distroless router (v0.1.12)#448
Merged
Conversation
…les), not the distroless router Every sandbox pod was stuck Init:CrashLoopBackOff on current-release AKS: egress-guard StartError exit=128 exec: "sh": executable file not found in $PATH The egress-guard init runs 'sh -c "iptables ..."' but was using the inference-router image, which became AL3 distroless (no sh, no iptables) in #383 — the same distroless migration that broke the controller probes. So the init crashlooped and no agent ever started. Fix: use ctx.sandbox_image for the egress-guard init. The sandbox base image installs iptables + util-linux and has a shell (Dockerfile.base:171), and is already pulled on the node (it's the agent container). Same image whose entrypoint does the equivalent iptables setup in Docker mode. Privilege envelope + iptables ruleset unchanged. Verified root cause on live cluster; cargo build --release + controller tests pass. Security audit: docs/internal/security-audits/2026-06-24-egress-guard-distroless-image.md Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Critical: every sandbox is stuck
Init:CrashLoopBackOffon current-release AKSConfirmed on a live cluster:
The egress-guard init container runs
sh -c "iptables ..."to install the per-pod egress lockdown, but it was using the inference-router image, which became AL3 distroless (nosh, noiptables) in #383 — the same distroless migration that broke the controller probes (fixed in v0.1.10). The init can't start → no sandbox ever runs.Fix
Use
ctx.sandbox_imagefor the egress-guard init. The sandbox base image installsiptables+util-linuxand ships a shell (sandbox-images/openclaw/Dockerfile.base:171), and it's already pulled on the node (it's the agent container) — no new image, no extra pull. It's also the same image whose entrypoint does the equivalent iptables setup in Docker mode, so K8s now matches Docker.Safety
Privilege envelope unchanged (
runAsUser:0,NET_ADMIN+NET_RAW, seccomp Unconfined, all else dropped) and the iptables ruleset is byte-identical. The guard was previously completely non-functional (fail-closed: nothing ran); this restores it.Verification
kars-inference-router:latest; sandbox base installs iptables).cargo build --release+ full controller test suite pass.Security audit:
docs/internal/security-audits/2026-06-24-egress-guard-distroless-image.md(2 sign-offs).Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com