Re: [openstack-dev] [ironic][neutron][keystone] how to reauth the token
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic][neutron][keystone] how to reauth the token
On 17 December 2015 at 02:59, Pavlo Shchelokovskyy < pshchelokovs...@mirantis.com> wrote: > 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). > > I'm not familiar with ironic as to what token is being passed around there. 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. 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. 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. 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. 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. [0] https://review.openstack.org/#/c/255885 > [1] > https://github.com/openstack/python-neutronclient/blob/master/neutronclient/client.py#L173 > > Best regards, > -- > Dr. Pavlo Shchelokovskyy > Senior Software Engineer > Mirantis Inc > www.mirantis.com > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic][neutron][keystone] how to reauth the token
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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic][neutron][keystone] how to reauth the token
On Wed, Dec 16, 2015 at 9:59 AM, Pavlo Shchelokovskyy < pshchelokovs...@mirantis.com> wrote: > 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). > 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: https://github.com/openstack/keystone/blob/70f3401d0b526fbb731df70512ad427a198990fd/etc/keystone.conf.sample#L1975-L1976 > [0] https://review.openstack.org/#/c/255885 > [1] > https://github.com/openstack/python-neutronclient/blob/master/neutronclient/client.py#L173 > > Best regards, > -- > Dr. Pavlo Shchelokovskyy > Senior Software Engineer > Mirantis Inc > www.mirantis.com > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [ironic][neutron][keystone] how to reauth the token
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). [0] https://review.openstack.org/#/c/255885 [1] https://github.com/openstack/python-neutronclient/blob/master/neutronclient/client.py#L173 Best regards, -- Dr. Pavlo Shchelokovskyy Senior Software Engineer Mirantis Inc www.mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
