Open Stack

On Thu, 2019-04-11 at 16:04 +1200, Jordan Ansell wrote:
> 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.
this is an interesting usecase and while this is not a part of the code
i useually deal with i be live your understand is correct in that we try
intentionally to use the users auth context wehre ever possible.

nova has/can have admin credential in its config for some service like
cinder and neutron however for security reasons(primarily try to not store
admin credentials on compute nodes) we try to not use the admin credentials.


i dont know if we have a config knob you can change to modify this behavior.
always using the admin credentials would be considerd an anti patteren
but i also know that some work has been done in keystone with system tokens?
servier tokens?  something like that may facilitate this usecase in the future.

hopefuly someone more knoladgeable in this area will chime in but in no surprised
that you have encountered issues with this configuration as it is not tested in the gate.
the default rule applie if its not tested assume its broken althohgh untested feature
do work more often then you would expect.
> 
> 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