<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 17 December 2015 at 02:59, Pavlo Shchelokovskyy <span dir="ltr"><<a href="mailto:pshchelokovskyy@mirantis.com" target="_blank">pshchelokovskyy@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<br><br>I'd like to start discussion on how Ironic is using Neutron when Keystone is involved.<br><br>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.<br><br>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.<br><br>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?<div><br></div><div>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).</div><div><br></div></div></blockquote><div> </div><div>I'm not familiar with ironic as to what token is being passed around there. <br><br></div><div>If it's the user's token there's really nothing we can do. You can't refresh a token a user gave you (big security issue) and using authentication plugins there really isn't going to help. In this case it's weird to pass both the token and the user/pass because assuming neutronclient allows that at all you're not going to know if you performed an operation as the user or the service.<br><br></div><div>If it's the token of the ironic service user (which seems possible because in that patch you've removed the else statement to always use the ironic service user) then yes if you were to use authentication plugins the token would be refreshed for you automatically because we have the username and password available to get a new token. <br><br></div><div>The only real option at the moment to extending the life of the user token is to establish a trust with keystone immediately on receiving the user token that delegates permission from the user to the service. You then use the service token (refreshable) to perform operations before returning to the user. This is what heat and recently glance (and others) have done to get around this problem. <br><br></div><div>There is ongoing work to solve this in a better way for all services but there is a lot to be done (change service->service communication everywhere) before this is available so if you are experiencing problems i wouldn't wait for it. <br><br></div><div>As a last aside, please create another section for the service user. You can use the same credentials but consider the keystone_authtoken section off limits. The options you are reading from there are old, not used in recent configurations (including devstack) and are going to mean that auth_token middleware in ironic can't be configured with v3, let alone cert based auth or any of the new things we are introducing there.<br></div><div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>[0] <a href="https://review.openstack.org/#/c/255885" target="_blank">https://review.openstack.org/#/c/255885</a><br>[1] <a href="https://github.com/openstack/python-neutronclient/blob/master/neutronclient/client.py#L173" target="_blank">https://github.com/openstack/python-neutronclient/blob/master/neutronclient/client.py#L173</a><br></div><div><br></div><div>Best regards,</div></div><span class="HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div dir="ltr"><span>Dr. Pavlo Shchelokovskyy</span><div>Senior Software Engineer</div><div>Mirantis Inc</div><div><a>www.mirantis.com</a></div></div>
</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>