This has a few serious implications:
a) A user can create a volume, retrieve the username/password from that volume, and use it to connect to a different tenant's volume. Most drivers create per-volume credentials.
b) A user can create a volume, retrieve the username/password from that volume, and use it to connect to the ScaleIO management API and presumably do lots of things they shouldn't be allowed to. Most drivers create credentials for volumes that are independent of the management credentials.
c) If the password is changed on the backend ScaleIO volumes that are currently being used stop working, because Nova stores the old password in its block_device_mapping table. (Not a security problem other than the fact that it prevents rotation of passwords, but definitely a bug.)
Parts of these issues are separately being looked at in bug 1736773, (which generally advises that in some clouds, only Nova should be able to see connection info, not end users) but the situation there is worse for the ScaleIO driver because most drivers only put usernames/passwords in connection_info that are usable for a single volume, not for the storage backend itself.
The ScaleIO driver uses the backend storage login and password for authentication for connections to the volume as well as the management API.
https:/ /git.openstack. org/cgit/ openstack/ cinder/ tree/cinder/ volume/ drivers/ dell_emc/ scaleio/ driver. py?h=13. 0.4#n176
https:/ /git.openstack. org/cgit/ openstack/ cinder/ tree/cinder/ volume/ drivers/ dell_emc/ scaleio/ driver. py?h=13. 0.4#n229
This has a few serious implications:
a) A user can create a volume, retrieve the username/password from that volume, and use it to connect to a different tenant's volume. Most drivers create per-volume credentials.
b) A user can create a volume, retrieve the username/password from that volume, and use it to connect to the ScaleIO management API and presumably do lots of things they shouldn't be allowed to. Most drivers create credentials for volumes that are independent of the management credentials.
c) If the password is changed on the backend ScaleIO volumes that are currently being used stop working, because Nova stores the old password in its block_device_ mapping table. (Not a security problem other than the fact that it prevents rotation of passwords, but definitely a bug.)
Parts of these issues are separately being looked at in bug 1736773, (which generally advises that in some clouds, only Nova should be able to see connection info, not end users) but the situation there is worse for the ScaleIO driver because most drivers only put usernames/passwords in connection_info that are usable for a single volume, not for the storage backend itself.