<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hello,<br>
    <br>
    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.<br>
    <br>
    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 <i>un</i>shelving.
    This should be controlled by a nova policy, however the user is
    unable to unshelve without permission to access the <i>cinder</i>
    API call "<a moz-do-not-send="true"
href="https://developer.openstack.org/api-ref/block-storage/v3/?expanded=initialize-volume-attachment-detail#initialize-volume-attachment">initialize_connection()</a>".
    Without granting permission to the user, cinder rejects nova's
    request with an HTTP 403 status message.<br>
    <br>
    Outcomes of this situation are, curious and potentially unwanted.
    Curious being the user is able to <i>shelve</i>. 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.<br>
    <br>
    I was looking for advice/opinions on this issue, and hope someone
    here can help or direct me to the right place.<br>
    <br>
    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!).<br>
    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 <i>user</i><i>'s</i>
    context instead of an internal nova <i>admin</i>-like context to
    call the cinder API.<br>
    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.<br>
    <br>
    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.<br>
    <br>
    Any help is much appreciated :)<br>
    Jordan<br>
  </body>
</html>