I am using Open Nebula on a number of servers, since using it I have been unable to get security groups working. The reason for this is due to the servers having routed subnets on a virtual bridge interface, the hosting provider also uses port security so I am unable to present any mac addresses except for the main interface mac address to the top of rack switch.
Out of the box the default security groups do not work with the above arrangement. The reason being is that they use -m physdev --physdev-is-bridged my setup is a routed not bridged so this rule never matches.
To solve my issue I found that the IPtables rules are created by security_groups_iptables.rb I have been modifying this file accordingly to create correct rules for my setup with success. However I would like to know if there is an offical way to be doing this? My concern is that during an upgrade my custom security_groups_iptables.rb will be overwritten. It does not feel like the correct way to be doing things and I was hoping a developer could provide reassurance that this is correct or point me in the right direction how I should be doing this?
Thank you in advance.
I’d say this is quite interesting. About your concerns, you are right whenever you upgrade your changes will be overwritten.
Could you make a PR with your changes to security_groups_iptables.rb so we can take a look at the changes? I’m thinking of two alternatives to handle this:
- Add a configuration option to the current iptables implementation
- Create a separate security group implementation (the code is prepared to implement the SG interface with any package filtering backend)
The right approach depends on the number of changes needed.
Thanks for your reply. No problem I shall create a PR for my changes. Out of interest do you have a guide for option 2? I have been looking through the source code recently and am fairly confident with Ruby. If you are able to give some pointers to create a security group implementation I am happy to give this a go with my requirements and then also get a PR opened for these changes.
Not really, we always though that implementing security groups with different technologies could be useful. At the end, only iptables was required, so implementing alternative backends is not exposed in a “user-friendly” way…
I am starting to figure it out looking through the source code.
vnm_mad/remotes I need to create a new implementation here e.g fw is for the current iptables implementation. I might create fw_forwarding and build out the associated files under here. Then update /etc/one/oned.conf to include a new VN_MAD_CONF I then need to build a new security_groups_iptables_forwarding.rb in vnm_mad/remotes/lib and also make the associated changes to the Sunstone frontend under public/app/tabs
Does it sound like I am on the right tracks?
I think the approach would be:
- Update the filter_driver to return the new class. Take a look at this function. We can start with an easy selector for the SG implementation by adding it in OpenNebulaNetwork.conf. You have access to a constant
CONF with the configuration.More information here.
- Create your own SGDriver class and return this class in the previous function when sg_iptables_type is forwarding (for example). I’d use the existing one as a template for the interface. Probably just replacing SGIPTables to SGIPTablesFW is a good start.
- Update your current security_groups_iptables.rb file to security_groups_iptablesfw.rb and change the names to match your changes in 2.
- Add the new files in the requires for the network drivers, here
- Be sure you place the new files in /var/lib/one/remotes and sync it to the hosts.
Maybe I’m missing something, but the main idea is to return a new object whenever a driver request the filter_driver, in this way a can use the new forwarding method with any of the existing drivers (802.1Q, vxlan…)
Got it, that makes sense to me.
In regards to point 1. with the selector in OpenNebulaNetwork.conf will adding a selector here also add that field in Sunstone? Or will I need to update the wizard and associated .js files to enable that?
Thank you for all the information so far it’s really pointing me in the right direction. I shall create a branch, make my changes and get a PR submitted once they are ready for review.
Ignore my question regarding OpenNebulaNetwork.conf I believe I have figured it out.
It provides a symbol in @nic[:conf] if I am not mistaken, whereby I can use this to determine which security group driver to use.
Thank you for feedback and interest!