NPEP-127: Add southbound traffic support in ClusterNetworkPolicy API#371
Open
tssurya wants to merge 2 commits into
Open
NPEP-127: Add southbound traffic support in ClusterNetworkPolicy API#371tssurya wants to merge 2 commits into
tssurya wants to merge 2 commits into
Conversation
Signed-off-by: Nadia Pinaeva <npinaeva@redhat.com>
- Update terminology from (B)ANP to ClusterNetworkPolicy - Fill in API section with networks and nodes fields on IngressPeer - Update API field descriptions to match egress side exactly - Add YAML examples for allow-from-CIDR and zero-trust patterns - Rewrite use cases to follow standard user story template - Add BGP/VM and ExternalTrafficPolicy=Local focused stories - Add Baseline tier and zero trust stories (refs kubernetes-sigs#248) - Move source IP preservation into introduction with BGP examples - Add Expected Behavior section covering source IP semantics, node.Status.Addresses matching, internal traffic, and kubelet probes (refs KEP-4559, kubernetes-sigs#314) - Add TBDs for secondary node IPs and allow-same-node semantic - Add conformance, alternatives, and references sections Signed-off-by: Surya Seetharaman <suryaseetharaman.9@gmail.com>
✅ Deploy Preview for kubernetes-sigs-network-policy-api ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: tssurya The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
approved
danwinship
reviewed
Apr 6, 2026
|
|
||
| ## Non-Goals | ||
|
|
||
| * N/A |
Contributor
There was a problem hiding this comment.
* Defining strict semantics for the source IPs of cluster-ingress traffic
| [Ingress API](https://kubernetes.io/docs/concepts/services-networking/ingress/), | ||
| [Gateway API](https://gateway-api.sigs.k8s.io/), or downstream | ||
| implementations like | ||
| [Openshift's Route API](https://docs.openshift.com/container-platform/4.13/rest_api/network_apis/route-route-openshift-io-v1.html). |
Contributor
There was a problem hiding this comment.
Suggested change
| [Openshift's Route API](https://docs.openshift.com/container-platform/4.13/rest_api/network_apis/route-route-openshift-io-v1.html). | |
| [OpenShift's Route API](https://docs.openshift.com/container-platform/4.13/rest_api/network_apis/route-route-openshift-io-v1.html). |
| original source IP is visible to the policy enforcement point. | ||
|
|
||
| In some deployments, pod IPs are directly routable from external | ||
| networks via BGP, and source IP is naturally preserved: |
Contributor
There was a problem hiding this comment.
Suggested change
| networks via BGP, and source IP is naturally preserved: | |
| networks, and source IP is naturally preserved: |
| // | ||
| // TBD: What about secondary node IPs or internal management | ||
| // IPs that are not in node.Status.Addresses? It's pretty hard | ||
| // to solve the case of ignoring externalIPs, egressIPs, KVIPs...and other corner cases |
Contributor
There was a problem hiding this comment.
We can't say "you can deny traffic from Node A to Pod B, but anybody on Node A can bypass the rule just by binding to an alternative source IP".
So either:
- The policy must apply to every IP on Node A which can be used for traffic between Node A and Pod B. OR
Nodesingress rules, likeDomainNamesegress rules, can only beAccept, notDeny(and then presumably apply to "whatever IP would be picked by default when routing a packet from Node A to Pod B", or maybe that plusnode.status.addresses)
| // well. So if you Accept or Deny traffic from "0.0.0.0/0", that will allow | ||
| // or deny all IPv4 pod-to-pod traffic as well. If you don't want that, | ||
| // add a rule that Passes all pod traffic before the Networks rule. | ||
| // |
Contributor
There was a problem hiding this comment.
need at least some of the "expected behavior" text from below here
Comment on lines
+249
to
+252
| 2. In deployments where pod IPs are directly routable (e.g. via BGP | ||
| with no overlay), the source IP of external traffic is the original | ||
| client IP. The `networks` peer will match against this IP as | ||
| expected. |
Contributor
There was a problem hiding this comment.
You can't say for sure that it's the "original" client IP, because the traffic may already have been masqueraded before it got to you. I would just drop this point.
| IP by kube-proxy or the load balancer. In this case: | ||
| - If `externalTrafficPolicy: Local` or equivalent source IP | ||
| preservation is configured, the original client IP is preserved | ||
| and can be matched by the `networks` peer. |
Contributor
There was a problem hiding this comment.
This needs to be split out into a separate point; right now you're saying that in the case where the traffic has been masqueraded, if it's eTP:Local, it won't have been masqueraded...
| - If source IP is not preserved, the `networks` peer will match | ||
| against the translated (e.g. node) IP, not the original client | ||
| IP. This is expected behavior -- the implementation matches what | ||
| it sees. |
Contributor
There was a problem hiding this comment.
If a Nodes peer allows from Node A, and traffic arrives at a NodePort on Node A and gets masqueraded, then does that imply it's accepted by the policy?
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
4 participants
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.
node.Status.Addresses matching, internal traffic, and kubelet
probes (refs KEP-4559, CNP vs kubelet probes #314)