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? __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
