Open Stack

Hello,

On Thu, Apr 11, 2019, at 01:25, Sean Mooney wrote:
> 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.

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.

Keystone's work with system scope[1] wouldn't really apply here, if I understand the situation correctly, because attaching a volume is an action that is specific to a resource within a project (tenant), it's not an action that affects the deployment as a whole or spans across multiple projects.

Hope this helps.

[1] https://docs.openstack.org/keystone/latest/contributor/services.html#system-scope

Colleen

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