This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

/sig Windows

/sig network
/cc @jayunit100 @sbangari @daschott

Yes, I don't think this field is supported on Windows today. +@princepereira as well for confirmation.

Looking for an update on this, please.

Pretty sure this isn't supported and also we don't test it at all .... I'll confirm

Yeah, confirmed its not implemented in the windows kernel proxy, at least, not as far as i can tell in the kernelspace proxy ... but maybe its possible in other windows proxies that are able to do things other than HNS.....

In the iptables impl, they use CIDR matching in the rules to do this .

In the iptables proxy: you can generally grok how this all works... (inside of the syncProxyRules ....

1. First

// make a firewall if there are LB Source Ranges (this cannot be done w/ HNS i dont think)
usesFWChain := ... (code that checks wether theres LBSourceRanges) ... 

2. Then

...
// read through all the whitelisted LBs and make rules for them so they pass through
for _, src := range svcInfo.LoadBalancerSourceRanges() {
  // 1) allow traffic from IP's matching this CIDR
  natRules.Write(args, "-s", src, "-j", string(externalTrafficChain))
  /// other logic to check whitelist if its from node ip

)

I dont think we CAN do this in the windows, HNS based proxy?

To my knowledge the HNS API Doesnt allow any kind of firewall / packet filtering functionality to do this, so we cant implement it easily i think in the windows kernel proxy. Unless you did some magic thing like looking at the actual packets in userspace or whatever....

@daschott to confirm?

cc @pramitagautam @tzifudzi for op-readiness we should doc this

Hi, the load balancer source ranges is not implemented for Windows... I have not looked at this in detail yet and am not familiar with the feature.

But HNS does have an ACL policy to allow/deny traffic based on CIDR, would that be suitable? This is used for example by npm & Calico...

sgtm, at least for now we can leave this bug open. will discuss in sig-windows this wk.

we'll leave this open. nobody on it yet though. we think we can impl it w/ the HNS ACLs....

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

@MikeZappa87

@jayunit100 did this ever get discussed at sig-windows? This issue might have fallen off the wagon. I didn't join sig-windows, do we triage at that meeting?

1. On one hand.... there is hope for this bc iirc we dug around and looked at the HNS parts and it does appear you could use windows firewall rules to implement some kind of lb source ranges functionality.

... but maybe

2. On the other hand we should leave this as a wontfix.... bc lbsourceranges needs to silently just go away?..... I think some folks ( @thockin ?) warned us about 6 years ago tho that lbSourceRanges was approaching firewall territory and should
   Probably be reconsidered.

Is this one of these cases where we have tests for this feature for Linux and they are not run on Windows nodes?

1. you can't really test LB source ranges easily at all because of the fact that I think we only test them for GCE

https://github.com/kubernetes/kubernetes/blob/master/test/e2e/framework/providers/gce/firewall.go ,

and I assume that test will go away once we impl the cloud provider migration?

Right now to test em I think it's a manual process where u grep your IP and then check if it's blocked properly..... not even sure there's a reliable cross platform test for this at all depending on snat and dnat behavior....?

2. Previous issues discussions have concluded I believe that this feature it at cloud provider discretion and may not work, where we interpret cloud provider as "the person setting up the cluster".... which means

So I'd propose:

"The administrator may know that their windows nodes don't support lb src ranges.... and in that case... the fact that they are not supported is a normal scenario".

1. To me that makes a case that this is a documentation issue - and maybe a feature request.... but It could go either way.

2. Either way if this is cross platform we need a cross platform non cloud provider specific test for it as well since cloud provider tests going away.

@AbelHu what should we do with this issue? Not sure if I clear path forward exists.

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".