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):
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