<div dir="ltr">Dear Cinder,<br><div><br></div><div>At my employer, Verizon Media, we want to implement a read only administrator like role using the Keystone default reader role scoped at system level. In the case of Nova, we've been following with interest their efforts here: <a href="https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:open+OR+status:merged)">https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:open+OR+status:merged)</a>. I decided to test the same approach with Cinder. The good news is that the policy.py modules are almost the same in Nova and Cinder. I then looked, though, at some API calls, like <a href="https://docs.openstack.org/api-ref/block-storage/v3/index.html#volumes-volumes">https://docs.openstack.org/api-ref/block-storage/v3/index.html#volumes-volumes</a>. The url in these calls include project_id, which in the case of a system scoped token I don't have. My questions are:</div><div><br></div><div>1) Am I missing something?</div><div>2) Are there any plans to implement a revision to these APIs in the near future so we can leverage the system scope and roles like reader for policy management?</div><div>3) One short term alternative in my case is to add "wrappers" to those API calls where we want to enable the reader role with system scope, extract the project_id from the context and forward the call to the regular API. Does this make sense? Are there any caveats to this?</div><div><br></div><div>Best regards</div><div><br></div><div>Miguel</div></div>