Unshelve in nova, cinder initialize_connection with user context

Jordan Ansell jordan.ansell at catalyst.net.nz
Thu Apr 11 04:04:20 UTC 2019


Hello,

I have encountered what appears to be an edge-case instance shelving
situation. I have to allow access to an internal API call to enable an
"unprivileged" user to perform an instance operation.

Specifically, I have a user with a "restricted permission" role in a
project, who should only be able to start/stop/shelve/unshelve an
existing instance. With sensible roles/actions in the nova policy, they
are able to perform all actions, except /un/shelving. This should be
controlled by a nova policy, however the user is unable to unshelve
without permission to access the /cinder/ API call
"initialize_connection()
<https://developer.openstack.org/api-ref/block-storage/v3/?expanded=initialize-volume-attachment-detail#initialize-volume-attachment>".
Without granting permission to the user, cinder rejects nova's request
with an HTTP 403 status message.

Outcomes of this situation are, curious and potentially unwanted.
Curious being the user is able to /shelve/. Which leads to a point of no
return for the user. But of particular concern is this API call exposes
the backend storage driver's connection info to users. The RBD driver,
as we use, does not even require a populated "connector" object before
it replies.

I was looking for advice/opinions on this issue, and hope someone here
can help or direct me to the right place.

My thoughts were that perhaps this is a bug or there's a configuration
issue with our nova/cinder (note, i'm using mitaka, so maybe it's fixed
upstream!).
I am unable to check whether this is just a bug in nova, due to my lack
of experience. But my rationale is nova is using the /user//'s/ context
instead of an internal nova /admin/-like context to call the cinder API.
As for configuration, I've been unable to pull up anything that seems
relevant to this issue looking through
/etc/{nova,cinder}/{nova,cinder}.conf, but maybe there's an option we've
enabled that's led to this behavior.

I'm happy to answer questions if anything is unclear. Sorry for
verbosity, vagueness or inaccuracies -- I'm very new to Openstack,
having started at zero a month ago and am using this task as a way to
learn more.

Any help is much appreciated :)
Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190411/444d466d/attachment.html>


More information about the openstack-discuss mailing list