[openstack-dev] [ironic][neutron][keystone] how to reauth the token

Adam Young ayoung at redhat.com
Thu Dec 24 02:01:39 UTC 2015


On 12/16/2015 01:59 PM, Clint Byrum wrote:
> Excerpts from Pavlo Shchelokovskyy's message of 2015-12-16 07:59:42 -0800:
>> Hi all,
>>
>> I'd like to start discussion on how Ironic is using Neutron when Keystone
>> is involved.
>>
>> Recently the patch [0] was merged in Ironic to fix a bug when the token
>> with which to create the neutronclient is expired. For that Ironic now
>> passes both username/password of its own service user and the token from
>> the request to the client. But that IMO is a wrong thing to do.
>>
>> When token is given but happens to be expired, neutronclient will
>> reauthentificate [1] using provided credentials for service tenant and user
>> - but in fact the original token might have come from completely different
>> tenant. Thus the action neutron is performing might look for / change
>> resources in the service tenant instead of the tenant for which the
>> original token was issued.
>>
>> Ironic by default is admin-only service, so the token that is accepted is
>> admin-scoped, but still it might be coming from different tenants (e.g.
>> service tenant or actual admin tenant, or some other tenant that admin is
>> logged into). And even in the case of admin-scoped token I'm not sure how
>> this will work for domain-separated tenants in Keystone v3. Does
>> admin-scoped neutronclient show all ports including those created by
>> tenants in domains other than the domain of admin tenant?
>>
>> If I understand it right, the best we could do is use keystoneauth *token
>> auth plugins that can reauth when the token is about to expire (but of
>> course not when it is already expired).
> Why not use trusts the way Heat does?

Too Heavyweight to create a trust for every request.  Better to make the 
Neutron user a trusted user and let the service do the operation implicitly.

>
> __________________________________________________________________________
> 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




More information about the OpenStack-dev mailing list