Repository navigation
feat: use namespaceSelector/podSelector for the ServiceX backend egress rule - #4
Merged
Merged
Conversation
…ss rule
The servicexBackend egress rule assumed an external ServiceX backend
and only supported an ipBlock CIDR. In practice the AF deployment's
ServiceX runs in the same cluster, and an ipBlock rule targeting its
Service ClusterIP never actually worked (this cluster's dataplane
evaluates egress after kube-proxy's DNAT rewrites the ClusterIP to a
backing pod IP), leaving 0.0.0.0/0 as the only option that functioned
-- far broader than intended.
Replace it with the same namespaceSelector/podSelector shape already
used for the jwks rule above it. No ipBlock fallback: this chart's
only real-world deployment has an in-cluster ServiceX backend, so
there's no reason to carry the external-backend case.
networkPolicy.egress.servicexBackend.namespaceSelector/podSelector
default to empty (matchLabels: {}) since there's no sensible
cluster-wide default -- every deployment's ServiceX namespace/pod
labels differ, same as config.servicexBackendUrl itself. NOTES.txt's
misconfiguration warning updated to match (empty selectors -> the
egress rule selects nothing -> redeem calls are blocked, rather than
the old "still wide open" warning).
Assisted-by: Claude Sonnet 5 <noreply@anthropic.com>
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.
Why
The servicexBackend egress rule assumed an external ServiceX backend and only supported an ipBlock CIDR. In practice the AF deployment's ServiceX runs in the same cluster, and an ipBlock rule targeting its Service ClusterIP never actually worked (this cluster's dataplane evaluates egress after kube-proxy's DNAT rewrites the ClusterIP to a backing pod IP), leaving
0.0.0.0/0as the only option that functioned -- far broader than intended.What
Replace it with the same namespaceSelector/podSelector shape already used for the
jwksrule right above it. No ipBlock fallback kept -- this chart's only real-world deployment has an in-cluster ServiceX backend.networkPolicy.egress.servicexBackend.namespaceSelector/podSelectordefault to empty (matchLabels: {}) since there's no sensible cluster-wide default.NOTES.txt's misconfiguration warning updated to match.Verification
helm lint/helm templateclean both with selectors set (renders the expected namespaceSelector/podSelector rule) and with defaults (renders the new NOTES.txt warning instead of erroring).🤖 Generated with Claude Code