<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 9:59 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></blockquote><div><br></div><div>Yeah, when the user's token expires, implementing a privilege escalation vulnerability as a workaround is not the ideal solution. Keystone does not implement a way to extend the expiration on bearer tokens - as that would present another security vulnerability - but you can increase the lifespan of all the tokens in your deployment using keystone.conf [token] expiration:</div><div><br></div><div>  <a href="https://github.com/openstack/keystone/blob/70f3401d0b526fbb731df70512ad427a198990fd/etc/keystone.conf.sample#L1975-L1976">https://github.com/openstack/keystone/blob/70f3401d0b526fbb731df70512ad427a198990fd/etc/keystone.conf.sample#L1975-L1976</a><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></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=""><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>