-
Notifications
You must be signed in to change notification settings - Fork 40k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenStack LBaaS integration missing Security Group Configuration #29745
Comments
It's actually worse than just having the no access from the default group, depending on the LBaaS driver in use, you will get totally different behaviors. e.g. with:
The load balancer port will be assigned to the projects default security group (as described in the original ticket)
The load balancer port will be assigned to a new security group within the octavia project/tenant - (i.e. not the same project/tenant that asked for a load balancer) |
…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) ```
…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) ```
Currently in LBaaS in openstack (v1 and v2), it puts the LBaaS port in the default security group only. Most environments have that set not to allow any traffic. There's a bug open to ask for a security group when creating an LB, but it hasn't gone anywhere. This means if you use this plugin with kubernetes, it with create the LB and assign a floating ip, but no one will be able to access it. the best fix is allow the config file to specify a security group id- the plugin would get the port_id of the LB after its created and then use update-port (http://gophercloud.io/docs/networking/#update-port) to add the security group to the port. if no security group was supplied in the config file it would behave as it does now.
The text was updated successfully, but these errors were encountered: