Allow configurable src range for type=loadbalancer firewall #20392
Comments
bprashanth
added
sig/network
|
I can take this up if no one else is working on it. |
|
@a-robinson any objections/plans? |
|
You should double check the relevant AWS/OpenStack Neutron APIs to make avoid ruling out compatibility in them, but going for it SGTM. |
|
Agree with checking. but if this ends up being a sneaky features that is not x-plat, we can just prefix the annotation with ".gce" and have everyone else ignore it. @kubernetes/goog-cluster fyi |
|
This is a good thing to try as an annotation, but we should just poke folks @justinsb @anguslees - do your respective load-balancer implementations Whatever we do, this is particular to type=LoadBalancer, so it should say On Mon, Feb 1, 2016 at 3:51 PM, Prashanth B notifications@github.com
|
|
These feature request bugs never explain what they're actually talking about :/ Assuming "apply that as the --source-ranges of the firewall" means only allowing certain remote source subnet(s) to access vip addresses on loadbalancers. I haven't experimented with the range of vendor drivers out there, but I fear the answer for OpenStack is "unsupported". |
|
AWS uses security groups for ELB ingress, so yes, it does support CIDR ingress restrictions. (It also supports restricting access to instances in specific security groups). I don't think it's unreasonable to throw an error if you try to create a LB on OpenStack with a CIDR source restriction. That's what we do e.g. if someone tries to create a UDP load balancer on AWS, and I haven't noticed many/any complaints about that. If it turns out to be important (if users report hitting the error) we could then implement IP filtering in e.g. kube-proxy. I suspect as long as we eventually support filtering for L7 ingress that we'll cover most use cases. |
|
As an evolution, it might be interesting to have per-namespace policy that enforces that services in a namespace must have a specific source-ips (or something like that) |
|
I'm assigning this to next milestone to decide whether and how to promote the annotation to a full feature. |
Automatic merge from submit-queue promote sourceRange into service spec @thockin one more for your pile I will add docs at `http://releases.k8s.io/HEAD/docs/user-guide/services-firewalls.md` cc: @justinsb Fixes: #20392
…urity-groups Automatic merge from submit-queue Security Group support for OpenStack Load Balancers <!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md 2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md 3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes --> **Add Security Group Support for OpenStack Load Balancers**: fixes #29745 adds OpenStack support to the work done in #20392 **Release note**: ``` This allows security groups to be created and attached to the neutron port that the load balancer is using on the subnet. The security group ID that is assigned to the nodes needs to be provided, to allow for traffic from the load balancer to the nodePort to be reflected in the rules. This adds two config items to the LoadBalancer options - ManageSecurityGroups (bool) NodeSecurityGroupID (string) ```
Automatic merge from submit-queue promote sourceRange into service spec @thockin one more for your pile I will add docs at `http://releases.k8s.io/HEAD/docs/user-guide/services-firewalls.md` cc: @justinsb Fixes: kubernetes#20392
…lancer-security-groups Automatic merge from submit-queue Security Group support for OpenStack Load Balancers <!-- Thanks for sending a pull request! Here are some tips for you: 1. If this is your first time, read our contributor guidelines https://github.com/kubernetes/kubernetes/blob/master/CONTRIBUTING.md and developer guide https://github.com/kubernetes/kubernetes/blob/master/docs/devel/development.md 2. If you want *faster* PR reviews, read how: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/faster_reviews.md 3. Follow the instructions for writing a release note: https://github.com/kubernetes/kubernetes/blob/master/docs/devel/pull-requests.md#release-notes --> **Add Security Group Support for OpenStack Load Balancers**: fixes kubernetes#29745 adds OpenStack support to the work done in kubernetes#20392 **Release note**: ``` This allows security groups to be created and attached to the neutron port that the load balancer is using on the subnet. The security group ID that is assigned to the nodes needs to be provided, to allow for traffic from the load balancer to the nodePort to be reflected in the rules. This adds two config items to the LoadBalancer options - ManageSecurityGroups (bool) NodeSecurityGroupID (string) ```
UPSTREAM: 66249: fill in normal restmapping info with the legacy guess Origin-commit: 0c4c2adde30ecd73cb895a2aaaecfc0cdf277921
UPSTREAM: 66249: fill in normal restmapping info with the legacy guess Origin-commit: 0c4c2adde30ecd73cb895a2aaaecfc0cdf277921
Users can set an annotation denoting a trusted src range and we can apply that as the --source-ranges of the firewall.
The text was updated successfully, but these errors were encountered: