[cinder] Implementing a read-only administrator with the default reader role and system scope
Dear Cinder, 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: https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:open...). 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 https://docs.openstack.org/api-ref/block-storage/v3/index.html#volumes-volum.... The url in these calls include project_id, which in the case of a system scoped token I don't have. My questions are: 1) Am I missing something? 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? 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? Best regards Miguel
On 9/23/19 5:48 PM, Miguel Lavalle wrote:
Dear Cinder,
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: https://review.opendev.org/#/q/topic:bp/policy-defaults-refresh+(status:open...). 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 https://docs.openstack.org/api-ref/block-storage/v3/index.html#volumes-volum.... The url in these calls include project_id, which in the case of a system scoped token I don't have. My questions are:
1) Am I missing something?
No, I don't think so.
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?
No plans at the current time, though the PTG hasn't happened yet. There are some checks deep down in Cinder independent of the policy file; before we make changes, there will need to be a lot of tests implemented so that we don't get regressions.
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?
Instead you might want to configure the Cinder policy file so that it behaves the way you want. You can use this document as a starting point: https://docs.openstack.org/cinder/latest/configuration/block-storage/policy-...
Best regards
Miguel
participants (2)
-
Brian Rosmaita
-
Miguel Lavalle