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