[openstack-dev] [nova][neutron] What to do about booting into port_security_enabled=False networks?
Matt Riedemann
mriedem at linux.vnet.ibm.com
Mon Apr 4 22:14:59 UTC 2016
On 4/1/2016 10:50 AM, Matt Riedemann wrote:
>
>
> On 3/31/2016 8:42 AM, Sahid Orentino Ferdjaoui wrote:
>> On Wed, Mar 30, 2016 at 09:46:45PM -0500, Matt Riedemann wrote:
>>>
>>>
>>> On 3/30/2016 5:55 PM, Armando M. wrote:
>>>>
>>>>
>>>> On 29 March 2016 at 18:55, Matt Riedemann <mriedem at linux.vnet.ibm.com
>>>> <mailto:mriedem at linux.vnet.ibm.com>> wrote:
>>>>
>>>>
>>>>
>>>> On 3/29/2016 4:44 PM, Armando M. wrote:
>>>>
>>>>
>>>>
>>>> On 29 March 2016 at 08:08, Matt Riedemann
>>>> <mriedem at linux.vnet.ibm.com <mailto:mriedem at linux.vnet.ibm.com>
>>>> <mailto:mriedem at linux.vnet.ibm.com
>>>> <mailto:mriedem at linux.vnet.ibm.com>>> wrote:
>>>>
>>>> Nova has had some long-standing bugs that Sahid is trying
>>>> to fix
>>>> here [1].
>>>>
>>>> You can create a network in neutron with
>>>> port_security_enabled=False. However, the bug is that
>>>> since
>>>> Nova
>>>> adds the 'default' security group to the request (if
>>>> none are
>>>> specified) when allocating networks, neutron raises an
>>>> error when
>>>> you try to create a port on that network with a 'default'
>>>> security
>>>> group.
>>>>
>>>> Sahid's patch simply checks if the network that we're
>>>> going
>>>> to use
>>>> has port_security_enabled and if it does not, no security
>>>> groups are
>>>> applied when creating the port (regardless of what's
>>>> requested for
>>>> security groups, which in nova is always at least
>>>> 'default').
>>>>
>>>> There has been a similar attempt at fixing this [2]. That
>>>> change
>>>> simply only added the 'default' security group when
>>>> allocating
>>>> networks with nova-network. It omitted the default
>>>> security
>>>> group if
>>>> using neutron since:
>>>>
>>>> a) If the network does not have port security enabled,
>>>> we'll blow up
>>>> trying to add a port on it with the default security
>>>> group.
>>>>
>>>> b) If the network does have port security enabled,
>>>> neutron will
>>>> automatically apply a 'default' security group to the
>>>> port,
>>>> nova
>>>> doesn't need to specify one.
>>>>
>>>> The problem both Feodor's and Sahid's patches ran into was
>>>> that the
>>>> nova REST API adds a 'default' security group to the
>>>> server
>>>> create
>>>> response when using neutron if specific security groups
>>>> weren't on
>>>> the server create request [3].
>>>>
>>>> This is clearly wrong in the case of
>>>> network.port_security_enabled=False. When listing security
>>>> groups
>>>> for an instance, they are correctly not listed, but the
>>>> server
>>>> create response is still wrong.
>>>>
>>>> So the question is, how to resolve this? A few options
>>>> come to mind:
>>>>
>>>> a) Don't return any security groups in the server create
>>>> response
>>>> when using neutron as the backend. Given by this point
>>>> we've cast
>>>> off to the compute which actually does the work of network
>>>> allocation, we can't call back into the network API to
>>>> see what
>>>> security groups are being used. Since we can't be sure,
>>>> don't
>>>> provide what could be false info.
>>>>
>>>> b) Add a new method to the network API which takes the
>>>> requested
>>>> networks from the server create request and returns a best
>>>> guess if
>>>> security groups are going to be applied or not. In the
>>>> case of
>>>> network.port_security_enabled=False, we know a security
>>>> group won't
>>>> be applied so the method returns False. If there is
>>>> port_security_enabled, we return whatever security
>>>> group was
>>>> requested (or 'default'). If there are multiple
>>>> networks on the
>>>> request, we return the security groups that will be
>>>> applied
>>>> to any
>>>> networks that have port security enabled.
>>>>
>>>> Option (b) is obviously more intensive and requires
>>>> hitting the
>>>> neutron API from nova API before we respond, which we'd
>>>> like to
>>>> avoid if possible. I'm also not sure what it means for the
>>>> auto-allocated-topology (get-me-a-network) case. With a
>>>> standard
>>>> devstack setup, a network created via the
>>>> auto-allocated-topology
>>>> API has port_security_enabled=True, but I also have the
>>>> 'Port
>>>> Security' extension enabled and the default public
>>>> external
>>>> network
>>>> has port_security_enabled=True. What if either of those
>>>> are
>>>> False
>>>> (or the port security extension is disabled)? Does the
>>>> auto-allocated network inherit
>>>> port_security_enabled=False?
>>>> We could
>>>> duplicate that logic in Nova, but it's more proxy work
>>>> that
>>>> we would
>>>> like to avoid.
>>>>
>>>>
>>>> Port security on the external network has no role in this
>>>> because this
>>>> is not the network you'd be creating ports on. Even if it had
>>>> port-security=False, an auto-allocated network will still be
>>>> created
>>>> with port security enabled (i.e. =True).
>>>>
>>>> A user can obviously change that later on.
>>>>
>>>>
>>>> [1] https://review.openstack.org/#/c/284095/
>>>> [2] https://review.openstack.org/#/c/173204/
>>>> [3]
>>>>
>>>> https://github.com/openstack/nova/blob/f8a01ccdffc13403df77148867ef3821100b5edb/nova/api/openstack/compute/security_groups.py#L472-L475
>>>>
>>>>
>>>> --
>>>>
>>>> Thanks,
>>>>
>>>> Matt Riedemann
>>>>
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>>
>>>> OpenStack Development Mailing List (not for usage
>>>> questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>
>>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>>
>>>>
>>>> <http://OpenStack-dev-request@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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>>
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>> Yup, HenryG walked me through the cases on IRC today.
>>>>
>>>> The more I think about option (b) above, the less I like that idea
>>>> given how much work goes into the allocate_for_instance code in
>>>> nova
>>>> where it's already building the list of possible networks that will
>>>> be used for creating/updating ports, we'd essentially have to
>>>> duplicate that logic in a separate method to get an idea of what
>>>> security groups would be applied.
>>>>
>>>> I'd prefer to be lazy and go with option (a) and just say nova
>>>> doesn't return security-groups in the REST API when creating a
>>>> server and neutron is the network API. That would require a
>>>> microversion probably, but it would still be easy to do. I'm not
>>>> sure if that's the best user experience though.
>>>>
>>>>
>>>> At the very least nova-api checks that the network exists before
>>>> proceeding; is it crazy or doable checking for the port security
>>>> attribute on the network and set a sentinel value for security groups
>>>> before moving on?
>>>>
>>>>
>>>> --
>>>>
>>>> Thanks,
>>>>
>>>> Matt Riedemann
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>>
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe:
>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>
>>>> <http://OpenStack-dev-request@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
>>>>
>>>
>>> Today the network_api.validate_networks method called from the
>>> compute API
>>> will check to see if the requested network exists (if one is
>>> requested), so
>>> we could check the port_security_enabled value on that network then.
>>> If no
>>> network is requested, we see if one is available to the project. If
>>> not, we
>>> don't allocate networks on the initial server create. But if that's the
>>> case, we'd just not return security groups I think since we don't know.
>>>
>>> In the case of get-me-a-network with the auto-allocated-topology, we
>>> could
>>> determine if security groups will be used by checking if the
>>> port-security
>>> extension is enabled.
>>>
>>> I'm not entirely sure how we'd get this information back from
>>> network_api->compute_api->REST API though. We could set something in the
>>> database for the instance and check that in the REST API, but that seems
>>> hacky.
>>
>> I think we do not have a real good solution to fix that case instead
>> of make the process "allocate networks for instance" synchrones so we
>> can retrieve network_info at this stage without to make the process to
>> heavy.
>>
>> I'd suggest to just remove that field when port security extension is
>> enable and no security groups has been passed to the request.
>>
>> s.
>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>> __________________________________________________________________________
>>>
>>> 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
>>
>
> OK, so here is what we're going to do.
>
> 1. Add a release note to Sahid's change
> https://review.openstack.org/#/c/284095/ saying that you can now boot
> servers into networks that don't have port security enabled. However,
> the server create response will still say that at least the default
> security group is applied, which would be wrong in this case. We should
> be able to backport this fix to stable branches.
>
> 2. We'll write up a spec to change the API response for server-create to
> return a link for getting security groups rather than the list of
> security groups we think are going to be applied (which might not be in
> the case of neutron). Something like:
>
> http://localhost:8774/v2.1/${project_id}/servers/{uuid}/os-security-groups
>
> This is similar to how the server resource has links for the flavor it
> was created with.
>
> That will go in a microversion (which we can't backport since it's an
> API change).
>
> --
>
> This is a bit of an odd case, but it's a trade-off to get the fix in
> since not being able to boot an instance into a network that doesn't
> have port security enabled is going to trump the UX in the server-create
> response. Also, listing the security groups after the server is created
> gives the correct results, so it's not like we're regressing that
> functionality.
>
I now have a spec for fixing the server create response body:
https://review.openstack.org/#/c/301372/
--
Thanks,
Matt Riedemann
More information about the OpenStack-dev
mailing list