fix(server,docs): reject gVisor + networkPolicy and document egress sidecar incompatibility#1070
fix(server,docs): reject gVisor + networkPolicy and document egress sidecar incompatibility#1070Pangjiping wants to merge 2 commits into
Conversation
…idecar incompatibility (#934) gVisor's netstack does not implement the iptables nat table, which the egress sidecar requires for DNS redirect. This caused silent CrashLoopBackOff when operators combined secure_runtime.type=gvisor with network_policy. - Add ensure_egress_runtime_compatible() validator that returns HTTP 400 when networkPolicy is requested under gVisor runtime - Wire validation into both K8s and Docker _ensure_network_policy_support() - Log startup warning when gVisor is configured alongside egress image - Add iptables nat row to compatibility matrix in docs/secure-container.md - Add troubleshooting entry for egress sidecar + gVisor failure - Add runtime compatibility section to docs/network-isolation-for-kubernetes.md - Add gVisor + egress e2e test case in kubernetes/test/e2e_runtime/gvisor/ Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Pangjiping
requested review from
Generalwin,
Spground,
fengcone,
hittyt,
jwx0925,
kevinlynx and
ninan-nn
as code owners
Pangjiping
added
bug
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dc8bf3ab1b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| and that the secure runtime supports the iptables nat table needed by the sidecar. | ||
| """ | ||
| ensure_egress_configured(request.network_policy, self.app_config.egress) | ||
| ensure_egress_runtime_compatible(request.network_policy, self.app_config.secure_runtime) |
There was a problem hiding this comment.
When Kubernetes users set runtimeClassName: gvisor through kubernetes.batchsandbox_template_file or agent_sandbox.template_file instead of [secure_runtime], this check still receives secure_runtime=None and allows networkPolicy. The providers later merge the runtime manifest into the base template, preserving a template runtimeClassName when the runtime pod spec does not override it, so the egress sidecar can still be created under gVisor and hit the CrashLoop this patch is intended to prevent. Please validate the effective RuntimeClass, including template-supplied values, before accepting the request.
Useful? React with 👍 / 👎.
…r+egress check Template-provided runtimeClassName bypassed the gVisor+egress validation because the check ran against secure_runtime config before the template merge. Now validate the assembled pod spec's runtimeClassName in each provider after merge_with_runtime_values, catching gVisor regardless of whether it came from config or template. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c50d35f74b
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| runtime_type = effective_runtime_class | ||
| if not runtime_type: | ||
| return | ||
| if runtime_type in _GVISOR_NAT_INCOMPATIBLE_RUNTIMES: |
There was a problem hiding this comment.
When the runtime comes from a template, effective_runtime_class is only the RuntimeClass object's name, but this rejects only the literal name gvisor. RuntimeClass names are deployment-defined while the handler identifies gVisor/runsc, so a template using a custom name such as runsc or gvisor-secure with handler runsc will still receive the egress sidecar and hit the gVisor CrashLoop this patch is meant to prevent. Please resolve the RuntimeClass handler or carry runtime type metadata for template-supplied classes.
Useful? React with 👍 / 👎.
1 participant
Summary
Closes #934
ensure_egress_runtime_compatible()validator that returns HTTP 400 whennetworkPolicyis requested undersecure_runtime.type=gvisor(gVisor lacks iptablesnattable required by the egress sidecar's DNS redirect)_ensure_network_policy_support()pathsiptables nat table (egress sidecar)row to compatibility matrix indocs/secure-container.mddocs/network-isolation-for-kubernetes.mdEGRESS_IMGnot set)Test plan
uv run pytest tests/— 1145 passedruff check— all checks passedEGRESS_IMG=opensandbox/egress:v1.0.12 go test ./test/e2e_runtime/gvisor/...on a gVisor-enabled cluster🤖 Generated with Claude Code