[RFE] Admin customized default security-group

[Roey Chen]

Allow the admin to decide which rules should be added (by default) to the tenant default security-group once created.

At the moment, each tenant default security-group is created with specific set of rules: allow all egress and allow ingress from default sg.
However, this is not the desired behavior for all deployments, as some would want to practice a “zero trust” model where all traffic is blocked unless explicitly decided otherwise, or on the other hand, allow all inbound+outbound traffic.
It’s worth nothing that at some use cases the default behavior can be expressed with very specific sets of rules, which only the admin has the knowledge to define (e.g- allow connection to active directory endpoints), in such cases the impact on usability is even worse, as it requires the admin to create rules on every tenant default security-group.

[Assaf Muller (amuller)]

Some history / context: https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group

[Armando Migliaccio (armando-migliaccio)]

This was rejected in the past. My sentiment hasn't changed.

[1] https://review.openstack.org/#/c/245537/

[Assaf Muller (amuller)]

I don't know if a blanket "won't fix" is appropriate given that we've seen the use case pop up time and time again. I would like to see a spec go forward so we could discuss the details there.

[Assaf Muller (amuller)]

I'd like to see this RFE discussed with the drivers team before it is marked as Won't Fix.

[Armando Migliaccio (armando-migliaccio)]

Fair enough.

As I mentioned in the past, config driven behavior is detrimental to interoperability and portability. Nothing stops the user to edit the default security groups themselves. For a zero-trust model that's where FWaaS comes in. I am happy to discuss further.

[Roey Chen (roeyc)]

I was thinking more in the lines of [1], which doesn't have pertain config driven behavior (I I've fully understand what you mean by that).

I can pick [1] and address old and new comments, also provide the implementation if the spec gets approved.

[1]: https://review.openstack.org/#/c/98966/

[Armando Migliaccio (armando-migliaccio)]

nova-network != neutron, and this was not considered a feature parity gap worth addressing.

[Armando Migliaccio (armando-migliaccio)]

I still think that for a zero trust model a more manageable and equivalent mechanism would lie into adopting FWaaS.

[Assaf Muller (amuller)]

Timing is an interesting consideration. This RFE is something that could be worked in Neutron in the next release, while FWaaS will probably take 3+ releases to become something usable.

[Ihar Hrachyshka (ihar-hrachyshka)]

I personally can't find a way that feature can be exposed without introducing incompatibility. See, a lot of users already assume and expect that default security group in Neutron has specific contents and behave in a specific way. Now, if we allow to change the contents, either through configuration files or via API, we introduce another set of calls for API users to run to validate that they will get the desired setup. Existing users and tools that are not aware of that potential new feature will not even check if default group is what they could expect from all previous releases, so they will just proceed with this assumption, getting either broken applications (in case of zero trust model applied by admin) or, even worse, getting instances silently exposed to external traffic that applications may be unprepared to deal with.

In that way, it does not really matter whether we expose it via config file; or api; whether we introduce a new api extension, or not... Someone is going to be screwed by us.

I prefer we don't pursue the idea. In the end, tenants are the ones to set models for their instances, not admins.

[Armando Migliaccio (armando-migliaccio)]

Status update:

http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-07-21-22.00.log.html#l-244

[Armando Migliaccio (armando-migliaccio)]

The driver team is divided on the use case, we should probably reach out to Nova folks and assess their opinion on the lack of parity and whether the customizability of the default security group is something they are after. Ultimately the decision lies with the Neutron team, and I believe there is a good rationale for rejection.

[Armando Migliaccio (armando-migliaccio)]

It would be nice to get someone from Nova to comment on Nova's ability to customize default security groups. I'll reach out and report back with my findings, for now marking INCOMPLETE.

[Armando Migliaccio (armando-migliaccio)]

Talking in the nova channel about this [1].

http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2016-07-28.log.html#t2016-07-28T18:42:28

[Armando Migliaccio (armando-migliaccio)]

After going through this report once again, Ihar's comments really resonate with me. If we go back and revisit this in the context of security groups, this may be indeed problematic. Even if we involved operators for feedback, reality is the default security group for Neutron has historically contained a specific set of rules; if we now allow the admin to change this, the aware user must discover the new rules by poking their default security group; the unaware one may unwillingly be exposed to a more lax set of rules.

If we deferred this use case scenario to FWaaS, I imagine that at least the unaware user would not get caught in the potential security hole as FWaaS cannot make security groups less restrictive.

[Armando Migliaccio (armando-migliaccio)]

Let's brainstorm a tad longer.

[Ihar Hrachyshka (ihar-hrachyshka)]

Armando, you mentioned in that irc chat that we should take the discussion of proposal merit to a (ops?) mailing list. Has it happened?

[Armando Migliaccio (armando-migliaccio)]

This thread is relevant:

http://lists.openstack.org/pipermail/openstack-dev/2016-November/106443.html

[Armando Migliaccio (armando-migliaccio)]

@Ihar: no, I did not follow up, but it looks like this surfaced again as noted above.

It is worth noting that this has not come up when soliciting for feedback at the design summit's ops sessions.

[Armando Migliaccio (armando-migliaccio)]

During today's drivers meeting, we finally came to the conclusion that albeit this is a valid use case, this should not be tackled by changing the default security group semantic, and instead work with the FWaaS team.

[1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2017/neutron_drivers.2017-01-19-22.02.log.html

[Armando Migliaccio (armando-migliaccio)]

I am going to mark this incomplete, for now. If you want to revisit to put emphasis on a FWaaS-based approach, then we can put it back on the queue.

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]