Open Stack

On 12/04/19 2:14 PM, Matt Riedemann wrote:
> On 4/11/2019 10:52 AM, Colleen Murphy wrote:
>> Forgive my unfamiliarity with the nova and cinder APIs but it sounds
>> like the shelve operation in nova is a purely nova-side API, while
>> the unshelve operation calls cinder's volume-attach API if the
>> instance had a mounted volume before it was shelved. Since the
>> operation involves cinder, you'd have to update the cinder policy to
>> allow this unprivileged user to perform the volume-attach action.
>> It's not really a bug, it's just fallout from having policies managed
>> separately for separate services.
>
> Correct, the user has to also be able to attach/detach volumes to/from
> their server since shelve/unshelve does that under the covers more or
> less.
>
> The same actually happens with ports, but you have to configure nova
> to have access to neutron's port binding API which is elevated (admin
> or service user token) beyond the normal user auth.
>
> Mitaka doesn't have configuration like that for cinder in nova, it was
> added a bit later but there is a patch being backported which you
> could also try to backport to mitaka - but it might be a bit messy
> (the keystoneauth stuff wasn't being used by nova in mitaka):
>
> https://review.openstack.org/#/c/603044/
>
Thank you for that, I'll have a look into it and see if this patch is
something we could use :)

And thanks too to Colleen and Sean for your comments earlier and link to
information about permission scope in keystone. Your comments, together
with what Matt is saying here tidies up my understanding of just what is
happening.

For now we have gone with a fix along the same vein as what Colleen
suggested, allowing the cinder os-initialize_connection action to be
performed by the restricted user.

Interesting to me is why nova (using the restricted user's context) is
able to perform the attach volume operation in full (starting a stopped
instance) but not the sub-operation of attaching a volume, just setting
up the volume connection (as with unshelving).

Also interesting is the connection information returned by the cinder
action we're discussing, as this "SAN" information of no /practical/ use
to a user and sensitive in some cases. It strengthens my belief that
something akin to the patch Matt has shared ought to be something we
consider.

Regards,
Jordan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190412/d8018e39/attachment.html>