Open Stack

On 17 December 2015 at 02:59, Pavlo Shchelokovskyy <
pshchelokovskyy at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151221/a924d5d7/attachment.html>