<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 12/04/19 2:14 PM, Matt Riedemann wrote:<br>
<blockquote type="cite"
cite="mid:bfa55204-5a19-fc69-87a9-09040cc703e9@gmail.com">On
4/11/2019 10:52 AM, Colleen Murphy wrote:
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.
<br>
<br>
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.
<br>
<br>
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):
<br>
<br>
<a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/603044/">https://review.openstack.org/#/c/603044/</a>
<br>
<br>
</blockquote>
Thank you for that, I'll have a look into it and see if this patch
is something we could use :)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
Also interesting is the connection information returned by the
cinder action we're discussing, as this "SAN" information of no <i>practical</i>
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.<br>
<br>
Regards,<br>
Jordan<br>
<br>
<br>
</body>
</html>