Open Stack

2017-04-28 7:03 GMT+09:00 Monty Taylor <mordred at inaugust.com>:
> On 04/25/2017 10:32 AM, Gary Kotton wrote:
>>
>> Hi,
>> I would like us to think of considering enabling an API that would allow
>> ‘deny’, for example an admin could overwrite a tenant’s security groups. For
>> example, and admin may not want a specific source range to access the
>> tenants VM’s. The guys working on FWaaS say that this may happen in V2, but
>> that looks very far away. Making this change in Neutron would be pretty
>> simple and give us a nice feature add.
>> If you would like to work on this I would be happy to develop this with
>> you. It could be added an extension.
>> Thanks
>> Gary
>>
>> On 4/24/17, 6:37 AM, "Ihar Hrachyshka" <ihrachys at redhat.com> wrote:
>>
>>     All traffic is denied by default. OpenStack security groups API is
>>     modeled to reflect what AWS does. You may find your needs better
>>     served by fwaas plugin for neutron that is not constrained by AWS
>>     compatibility.
>
>
> OpenStack does not claim to have or strive for AWS compatibility.
>
> It is not a goal. It may have been one for someone during the writing of the
> security-groups code, and thus may be a good description of why the
> security-groups are structured and behave the way they do. Moving forward,
> AWS compatibility should really never be a reason we do or don't do
> something if that thing is beneficial to our users.

I think one good reason that neutron security group only supports
whitelist rules
is to keep rule management simple.
If we support black list rules (i.e., deny/reject rules), users need
to consider the order of rules.
If blacklist rules and whitelist rules have overlapped areas, we need
priority of rules.
Supporting whitelist rules only makes rule management really simple and
I believe this is what is the security group API.

The rough consensus of the neutron community is that more complicated rules
like blacklist rules or rule priorities should go to FWaaS.

This topic was discussed several times in the neutron history and as of now
the above and what Gary and Ihar commented is our consensus.
The main background of the consensus is not just because of AWS compatibility.
In my understanding it is because what current users expect on the
security group.
Isn't it confusing that blacklist or rule priority is introduced at
some point from user perspective?

There are still gray zones. For example, a request we received multiple times
is "can neutron provide a way to define a set of default rules for a
new security group?".
It happened several months ago and at that time the proposal was rejected
because it changes what users have even though a feature is discoverable.


>
>
>>     On Sun, Apr 23, 2017 at 8:33 PM, 田明明 <tianming20052004 at 163.com> wrote:
>>     > Can we add an "action" to security group rule api, so that we could
>> dispatch
>>     > rules with "deny" action? Until now， security group only supports
>> add
>>     > white-list rules but this couldn't satisfy many people's needs.
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>>     >
>> __________________________________________________________________________
>>     > OpenStack Development Mailing List (not for usage questions)
>>     > Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>     >
>>
>>
>> __________________________________________________________________________
>>     OpenStack Development Mailing List (not for usage questions)
>>     Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev