This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
Bug 1258455 - [RFE][neutron]: Enable setting default rules for default security group
Summary: [RFE][neutron]: Enable setting default rules for default security group
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: Slawek Kaplonski
QA Contact: Toni Freger
URL: https://blueprints.launchpad.net/neut...
Whiteboard: upstream_milestone_none upstream_defi...
: 886303 1763942 (view as bug list)
Depends On:
Blocks: 2070140
TreeView+ depends on / blocked
 
Reported: 2015-08-31 12:25 UTC by Pablo Iranzo Gómez
Modified: 2024-03-25 14:55 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 2070140 (view as bug list)
Environment:
Last Closed: 2023-10-20 20:00:11 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1592000 0 None None None 2016-06-14 11:32:38 UTC
Launchpad 1983053 0 None None None 2022-07-28 19:12:13 UTC
Red Hat Issue Tracker OSP-2897 0 None None None 2021-11-24 19:44:13 UTC
Red Hat Issue Tracker   OSPRH-515 0 None None None 2023-10-20 20:00:10 UTC
Red Hat Knowledge Base (Solution) 2323201 0 None None None 2020-07-05 11:45:23 UTC
Red Hat Knowledge Base (Solution) 3420811 0 None None None 2020-07-05 11:44:27 UTC

Description Pablo Iranzo Gómez 2015-08-31 12:25:52 UTC 
Request to include https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group.

Description:

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
Comment 4 Nir Yechiel 2015-09-24 10:57:52 UTC 
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.
Comment 5 Pablo Iranzo Gómez 2015-10-14 08:02:20 UTC 
Hi Nir,

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.

Thanks,
Pablo
Comment 6 Assaf Muller 2016-04-12 00:19:30 UTC 
*** Bug 886303 has been marked as a duplicate of this bug. ***
Comment 13 Ihar Hrachyshka 2017-08-11 18:57:20 UTC 
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).
Comment 16 Nir Yechiel 2018-03-17 23:41:28 UTC 
Closing this RFE based on comment #13 above.
Comment 17 David Hill 2020-07-05 11:31:03 UTC 
Hi guys,

   We do have some customers requesting this feature over and over again.   Did things evolve in the right direction since 2015-2018 that would allow us to have some sort of default security groups for new tenants ?     That would really help operators automate further some manual work that we are trying to automate with all those cloud APIs but we have to ways of saying "allow icmp, tcp port 22 and tcp port 3389 for all new guests using this new tenant" .   

Thank you very much,

David Hill
Comment 18 Allan Greentree 2020-07-16 17:18:36 UTC 
Hello,

Per David's previous comment, this customer is asking for this enhancement, please let us know if/when possible - https://access.redhat.com/support/cases/#/case/02694779

Thanks, Allan Greentree
Red Hat OpenStack Support
Comment 24 Eric Nothen 2021-11-24 19:42:24 UTC 
(In reply to Ihar Hrachyshka from comment #13)
> 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).

Is it still the case that it is impossible to implement this feature in a backwards compatible way, or did things evolve since 2017 in a direction that would facilitate development of the requested feature? If the former, shouldn't this BZ be closed as WONTFIX so that we don't keep associating cases here? If the latter, can someone on the DFG reevaluate the comment above and give an estimation of what it would take to complete this feature and what is the most optimistic target release?

Thanks in advance.
Comment 25 aruffin@redhat.com 2022-02-10 22:10:23 UTC 
We have a customer that also needs this functionality.  Repeating Eric Nothen's request, can someone on the DFG reevaluate the comment above and give an estimation of what it would take to complete this feature and what is the most optimistic target release?
Comment 36 Conrado Gusso Bozza 2022-07-29 13:55:07 UTC 
Hi,

It is the same the customer is asking for.
Comment 40 Slawek Kaplonski 2023-07-24 10:23:19 UTC 
*** Bug 1763942 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.