[heystone][nova][cinder] netapp queens trust scoped token

Ignazio Cassano ignaziocassano at gmail.com
Sat Jan 19 07:44:54 UTC 2019


Hello Lance, application credential are also supported in queens?
Thanks
Ignazio


Il giorno Ven 18 Gen 2019 16:04 Lance Bragstad <lbragstad at gmail.com> ha
scritto:

>
>
> On Fri, Jan 18, 2019 at 6:49 AM Ignazio Cassano <ignaziocassano at gmail.com>
> wrote:
>
>> Hello Everyone,
>> I am using a client for backupping openstack virtual machine.
>> The crux of the problem is the client uses trust based authentication for
>> scheduling backup jobs on behalf of user.  When a trust scoped token is
>> passed to cinder client to take a snapshot, I expect the client use the
>> token to authenticate and perform the operation which cinder client does.
>> However cinder volume service invokes novaclient as part of cinder nfs
>> backend snapshot operation and novaclient tries to re-authenticate. Since
>> keystone does not allow re-authentication using trust based tokens, cinder
>> snapshot operation fails.
>>
>>
> Keystone allows authorization by allowing users to scope tokens to trusts,
> but once a trust-token is scoped, it can't be rescoped. Instead, keystone
> requires that you build another authentication request for a new
> trust-scoped token using the trust [0][1].
>
> [0]
> https://developer.openstack.org/api-ref/identity/v3-ext/index.html?expanded=consuming-a-trust-detail#id121
> [1]
> https://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/plugins/token.py#n84
>
>
>> So I get the following error:
>>
>> 2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs [req-61d977c1-eef3-4309-ac02-aaa0eb880925
>> ab1bdb5dadc54312891f3a6410fef04d 6d1bffb04e3b4cdda30dc17aa96bfffc - default
>> default] Call to Nova to create snapshot failed: Forbidden: You are not
>> authorized to perform the requested action: Using trust-scoped token to
>> create another token. Create a new trust-scoped token instead. (HTTP 403)
>> (Request-ID: req-f55b682a-001b-4952-bfb1-abf4dd6bf459)
>>
>>  >  2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs Traceback
>> (most recent call last):
>>
>>  >  2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs
>> File "/usr/lib/python2.7/site-packages/cinder/volume/drivers/ remotefs.py",
>> line 1452, in _create_snapshot_online
>>
>>  >  2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs
>>   connection_info)
>>
>>  >  2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs
>> File "/usr/lib/python2.7/site-packages/cinder/compute/nova.py", line 188,
>> in create_volume_snapshot
>>
>>  >  2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs
>>   create_info=create_info)
>>
>>  >  2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs
>> File
>> "/usr/lib/python2.7/site-packages/novaclient/v2/assisted_volume_snapshots.py",
>> line 43, in create
>>
>>  >  2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs
>>   return self._create('/os-assisted-volume-snapshots', body, 'snapshot')
>>
>>  >  2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs
>> File "/usr/lib/python2.7/site-packages/novaclient/base.py", line 361, in
>> _create
>>
>>  >  2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs
>>   resp, body = self.api.client.post(url, body=body)
>>
>>  >  2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs
>> File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 310,
>> in post
>>
>>  >  2018-12-12 04:07:14.759 2859 ERROR cinder.volume.drivers. remotefs
>>   return self.request(url, 'POST', **kwargs)
>>
>>
>> My cinder volume are non netapp fas8040 via nfs.
>>
>> Anyone can help me ?
>>
>
> There is another feature in keystone that sounds like a better fit for
> what you're trying to do, called application credentials [2]. Application
> credentials were written as a way for users to grant authorization to
> services and scripts (e.g., the scipt asking cinder for a snapshot in your
> case.)
>
> Application credentials aren't tokens, but your scripts can use them to
> authenticate for a token [3]. The keystoneauth library already supports
> application credentials, so if you use that for building a session you
> should be able to use it in other clients that already support keystoneauth
> [4].
>
> [2]
> https://docs.openstack.org/keystone/latest/user/application_credentials.html
> [3]
> https://docs.openstack.org/keystone/latest/user/application_credentials.html#using-application-credentials
> [4]
> https://docs.openstack.org/keystoneauth/latest/authentication-plugins.html#application-credentials
>
>>
>> Regards
>>
>> Ignazio
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190119/60846fd7/attachment-0001.html>


More information about the openstack-discuss mailing list