Comment 9 for bug 1736773

We talked about this at length in the nova/cinder cross-project meeting today:

http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-12-07-16.00.log.html#l-19

To try and summarize, there are 5 APIs in cinder with this issue:

1. The os-initialize_connection volume action API which is controlled by an admin_or_owner policy rule (not documented in the API reference).

2. The create attachment API (there is no policy rule by default for this):

https://developer.openstack.org/api-ref/block-storage/v3/#create-attachment

4. The attachment_update API (PUT /v3/{project_id}/attachments/{attachment_id}) which is controlled by an admin_or_owner policy rule.

https://developer.openstack.org/api-ref/block-storage/v3/#update-an-attachment

5. The show attachment API:

https://developer.openstack.org/api-ref/block-storage/v3/#show-attachment-details

6. The list attachments with details API:

https://developer.openstack.org/api-ref/block-storage/v3/#list-attachments-with-details

There are no direct policy checks on #5 or #6. If you're showing details about an attachment id, you have to be an admin or owner to lookup the record from the database, same for #6 - you can only list attachments that you are the owner if via the model query in the database.

Impacts to consumers:

If we added an admin-only by default policy rule to restrict showing the connection_info in the response, that would break any existing nova deployment that doesn't have the [cinder] section in nova.conf configured with a user that has the admin role. There is nothing documenting the need for an admin user for nova to talk to cinder today:

https://docs.openstack.org/cinder/latest/install/cinder-controller-install-ubuntu.html#configure-compute-to-use-block-storage

And devstack doesn't set that up either (for reference):

https://github.com/openstack-dev/devstack/blob/d37119e797d3140aeb0038a1129ce5e9016c1a36/lib/nova#L470-L476

If you compare that to nova's communication with neutron, nova indeed does require that it's configured with a user that has the admin role so it can use the networking service port binding API. It's less obvious, but you can infer from the networking install guide that is required:

a) https://docs.openstack.org/neutron/latest/install/controller-install-ubuntu.html

"Add the admin role to the neutron user"

b) https://docs.openstack.org/neutron/latest/install/compute-install-ubuntu.html#configure-the-compute-service-to-use-the-networking-service

^ tells you to configure nova.conf to use the neutron user, which is an admin user.

Given this, no deployments today require that the cinder section of nova.conf be configured with an admin user. Adding an admin-only policy rule to existing APIs that nova uses would break anyone that doesn't also configure nova to use an admin user for cinder.

Therefore, I think if policy rules are added to Cinder to mask the connection_info in the response for those APIs mentioned above, it will have to default to admin_or_owner to not break existing deployments, and then fully document the fact that for any deployment which wants to make that admin-only, they will also need to configure nova.conf's [cinder] section to use an admin user, it's definitely a 2-step process to turn this on and not break things.