Red Hat Bugzilla – Bug 1258455
[RFE][neutron]: Enable setting default rules for default security group
Last modified: 2018-03-17 19:41:28 EDT
Request to include https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group.
We already have this feature in nova when using nova as security driver implementation, providing a hook mechanism to add customized rules when creating default security groups, so that we don't have to remind users to modify default security group at the first time they create instances.
But This feature has been lost when neutron is used. It's worthwhile for this useful feature to be reimplemented in neutron.
Customer wants to be able to define default SG set when creating new tenants
Can you please clarify the use-case for this request?
Note that ML2 port-security extension was added in RHEL OpenStack Platform 7. This allows to disable the security-group feature (including the anti-spoofing rules) on a per port basis, so that customers should be able to deploy VNF applications inside VMs without interruption from Neutron. I am not sure if the helps here or not.
As discussed with Sadique, this is for allowing the modification the rules that are in place when a new security group is created.
Customer is interested in OSP reseller functionality and want to be able to define the default rules to be created on each new SG defined.
*** Bug 886303 has been marked as a duplicate of this bug. ***
To give context here, the feature was extensively discussed in upstream community for a long time, and the decision there is that it's impossible to implement the feature in a backwards compatible way for security groups that are established API for which existing users have behavioral assumptions (incl. the fact that default behavior allows outgoing connections). The suggestion from the upstream drivers (design) team is to explore alternative API for that matter, f.e. building it on top of fwaas-v2 API that is still experimental.
Realistically, to get the feature implemented and supported in OSP, significant amount of engineering work is expected, including first helping fwaas community to build fwaas-v2 as a viable alternative for fwaas-v1 (v2 is still experimental and incomplete, and there is no clear ETA as to when it will mature).
Closing this RFE based on comment #13 above.