[openstack-dev] [Neutron]Do you think tanent_id should be verified

Dolph Mathews dolph.mathews at gmail.com
Wed Feb 19 20:33:52 UTC 2014


There's an open bug [1] against nova & neutron to handle notifications [2]
from keystone about such events. I'd love to see that happen during Juno!

[1] https://bugs.launchpad.net/nova/+bug/967832
[2] http://docs.openstack.org/developer/keystone/event_notifications.html

On Mon, Feb 17, 2014 at 6:35 AM, Yongsheng Gong <gongysh at unitedstack.com>wrote:

> It is not easy to enhance it. If we check the tenant_id on creation, if
> should we  also to do some job when keystone delete tenant?
>
>
> On Mon, Feb 17, 2014 at 6:41 AM, Dolph Mathews <dolph.mathews at gmail.com>wrote:
>
>> keystoneclient.middlware.auth_token passes a project ID (and name, for
>> convenience) to the underlying application through the WSGI environment,
>> and already ensures that this value can not be manipulated by the end user.
>>
>> Project ID's (redundantly) passed through other means, such as URLs, are
>> up to the service to independently verify against keystone (or
>> equivalently, against the WSGI environment), but can be directly
>> manipulated by the end user if no checks are in place.
>>
>> Without auth_token in place to manage multitenant authorization, I'd
>> still expect services to blindly trust the values provided in the
>> environment (useful for both debugging the service and alternative
>> deployment architectures).
>>
>> On Sun, Feb 16, 2014 at 8:52 AM, Dong Liu <willowd878 at gmail.com> wrote:
>>
>>> Hi stackers:
>>>
>>> I found that when creating network subnet and other resources, the
>>> attribute tenant_id
>>> can be set by admin tenant. But we did not verify that if the tanent_id
>>> is real in keystone.
>>>
>>> I know that we could use neutron without keystone, but do you think
>>> tenant_id should
>>> be verified when we using neutron with keystone.
>>>
>>> thanks
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140219/d815c6db/attachment.html>


More information about the OpenStack-dev mailing list