Volume details shows attached compute host for non-admins
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Cinder |
Fix Released
|
Undecided
|
Rajat Dhasmana | ||
OpenStack Security Advisory |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
The Cinder API shows attached attachments with volume details, and it includes the attached_host information for the attachments, if present, regardless of whether or not an admin token is being used:
This means a non-admin can see compute host details when a volume is attached to their instance.
This is easily recreatable in devstack:
1. Show that I'm the demo user (can't perform admin things like service-list):
stack@queens:
ERROR (Forbidden): Policy doesn't allow os_compute_
2. Create a server and a volume and attach the volume to the server:
stack@queens:
+------
| Property | Value |
+------
| device | /dev/vdb |
| id | 373c2a29-
| serverId | 43bc2379-
| volumeId | 373c2a29-
+------
stack@queens:
+------
| ID | Name | Status | Size | Attached to |
+------
| 373c2a29-
3. Show the volume details to see the attachment and the attached_host:
stack@queens:
+------
| Field | Value |
+------
| attachments | [{u'server_id': u'43bc2379-
You can see that the host_name is in the response and the value is "queens" which is the compute hostname on this single-node install:
stack@queens:
queens
This is using LVM by default with devstack. I tried the same thing against vexxhost and host_name came back as None, so it might be backend-specific (vexxhost is using Rbd).
This is the vexxhost output for the same scenario:
(vexxhost) user@ubuntu:~$ openstack volume show test-vol1
+------
| Field | Value |
+------
| attachments | [{u'server_id': u'd1643bfb-
--
This has been around since Havana: https:/
This is significant because the default compute API policy is to not show the compute host/node information for a server instance for non-admin users, but with this exposure in the Cinder API, non-admin users can get around that restriction (potentially - again, it seems to depend on volume backend) to see the compute host on which the volume is attached.
I believe I've found the issue, and it's a regression in the 3.27 Cinder volume attachment_update API:
PUT /volumes/ {id}/attachment s/{attachment_ id}
The volume manager code is updating the volume with the host from the connector dict, which nova gets from os-brick, and setting that on the volume here:
https:/ /github. com/openstack/ cinder/ blob/a95c9e5668 f6a7596e0198cca 2b6b7fef20ab3e9 /cinder/ volume/ manager. py#L4370
Nova only started using this code as of this change:
https:/ /review. openstack. org/#/c/ 330285/
Which is not released yet.
That's also the reason why I couldn't reproduce this on vexxhost since they are running Pike code. And before https:/ /review. openstack. org/#/c/ 330285/, nova would call the os-attach volume actions API but never passed a host name directly for that, so this was always None:
https:/ /github. com/openstack/ cinder/ blob/master/ cinder/ volume/ manager. py#L1189
So the question is what to do about this before the Queens release. There are a couple of options:
1. Add a policy rule in Cinder to not expose the attached_host field in the response to non-admins. To not break backward compatibility, you'd likely need to default this to allow admin_or_owner.
2. Don't store the attached_host value when calling attachment_update, and if some client needs to actually set the hostname for the attachment to get it later, like glance, it should use the os-attach volume action API.