Restrict agent-phase DNS egress to cluster DNS - #471
Open
knyazev741 wants to merge 1 commit into
Open
Conversation
The ridges-agent-egress NetworkPolicy allowed UDP/TCP 53 to 0.0.0.0/0 (no `to:` selector). Agent pods could therefore query arbitrary authoritative DNS servers, opening a DNS-tunneling channel out of the sandbox: low-bandwidth, but enough to exfiltrate data or relay traffic to non-whitelisted endpoints, bypassing the SNI allowlist that gates port 443. Scope DNS egress to kube-system (kube-dns / CoreDNS, and node-local-dns DaemonSets where present), which is where every cluster's resolver lives. Legitimate resolution is unaffected; the HTTPS path via the iptables REDIRECT + SNI router is unchanged.
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.
What
ridges-agent-egressDNS rule to cluster DNS (kube-systemnamespace selector) instead of leaving UDP/TCP 53 open to0.0.0.0/0Why
During the agent phase, port 443 egress is transparently intercepted (iptables REDIRECT) and gated by the proxy's SNI allowlist — but port 53 was open to the entire internet. Agent code could query arbitrary authoritative DNS servers, which is a working DNS-tunneling channel out of the sandbox: low bandwidth, but sufficient to exfiltrate data or relay traffic to non-whitelisted endpoints, bypassing the SNI allowlist entirely.
Scoping DNS egress to
kube-system(kube-dns / CoreDNS, and node-local-dns DaemonSets where present) closes this gap while leaving legitimate resolution untouched — agent pods resolve through the cluster resolver anyway. The HTTPS interception path is unchanged.Validation
git diff --checkcleank8s/localsmoke run to confirm CoreDNS resolution still works for agent podsRelated
While you're in the sandbox/networking corner — I'd appreciate a look at #469 (adds
deepseek-ai/DeepSeek-V4-Flash-0731to the OpenRouter whitelist; minimal, fully unit-tested, no paid inference calls) and #470 (Gonka provider for Kimi K2.6; larger, operator-controlled broker design). #469 in particular is a small low-risk addition that would immediately let miners evaluate against the new DeepSeek V4 Flash.