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