ACL(access control list) Rule for Cinder Volumes

Design discussion on the etherpad:
https://etherpad.openstack.org/p/icehouse-cinder-acls-for-volumes

Can we reuse the swift ACL rules / style? -- DuncanT

This bp has commonalities with the blueprint https://blueprints.launchpad.net/keystone/+spec/fine-grain from Keystone.

I am reaching out to Joe Savak and Michael Scott. Whn they are ready, we will work together implement both of them.

~~~~~~~~~~~~~~~~~~~~~~~~~

<jdg>

I think the volume transfer feature covers this use case, but if there are others we can certainly revisit.

Gerrit topic: https://review.openstack.org/#q,topic:bp/volume-acl,n,z

Part 1.
Addressed by: https://review.openstack.org/43453

Add Volume ACL Permissions: DB

Part 2.
Addressed by: https://review.openstack.org/43454

    Add Volume ACL Permissions: Volume ACL Module

Part 3.
Addressed by: https://review.openstack.org/39683

    Add Volume ACL Permissions: API extension

(Detailed design)From Vincent Hou:

The users can be classified into 4 types, which are Administrator, Owner/Creator, users with "Permission Write" and users without "Permission Write". The leftmost column contains all the permissions and the topmost row lists all the users. This table indicates the relationship about who is able or unable to change whose permission.

An administrator can change the permissions can change the permissions of all the other users. The administrator always has the full permission, so it is marked as "NA" for whether an administrator can change the permission of an administrator.

The owner/creator of the volume can change the permissions of other users except the administrators. It is possible that the owner/creator change his owner permission, since cinder support "volume ownership transfer". If the volume transfers the ownership to another user, the owner will change his permission. Under other conditions, the owner won't change his owner permission.

Users with "Permission Write" are able to change their own permissions and the permissions of the users without "permission write". However, they are unable to change the permissions of the admins and the owner, even if they have the "Full Access" permission. We can allow this type of user to change his owner permission, but an interesting case will happen when he change his permission from "permission write" to "permission read". After this operation, he becomes a user without "Permission Write", and he won't be able to change his permission back any more.

Users without "Permission Write" are not able to change the permissions at all.

The users without "Permission Write" means users with "write + permission write" aka users with "Full access".

The users without "Permission Write" include users with "read", users with "write", users with "read + permission read", and users with "write + permission read".

Explanations about users with "read + permission write" and "write + permission write":

I think both of the types can be merged into users with "Full access". Why? Suppose a user has "permission write" to an volume, even if he has read-only access, he can easily change his permission into write access. In consequence, he becomes a user with "write+permission write". Permission "write+permission write" is already the highest authority for the users except the owner and the administrators, so it turns out to be a user with "Full access".

Explanations about users with "permission read":

This type of users can see who has which kind of permissions to the volume. They know who has the access and what kind of access to the volume, but unable to change them. For example, he can know who has the "read-only", who has the "write", who has "permission read", who has "permission write", etc.

For users with "read" or "write", they are unable to see the permission list of the volume. They don't know who has the access to the volume.

<jdg>
Just some additional thoughts, starting the review process on your patch here: https://review.openstack.org/#/c/39683/

As I mentioned before we seem to be solving one problem in multiple ways (public volumes, tenant-transfer and now ACL). So out of the three actually ACL is IMO the most needed and desirable. After this is released however I have to question the value of public volumes, and the tenant transfer implementation use case can also be set by adjusting the ACL's (adding or removing members).

Anyway, just something I've been thinking about the past couple of weeks and I'd be curious to hear your thoughts as well as other peoples thoughts regarding this.

Gerrit topic: https://review.openstack.org/#q,topic:bp/read-only-volumes,n,z

==========================================================
The previous design is out of date. There is a new one.

Detailed design

ACL brings the following functionality. The volume owner and the administrators have the full access to a volume, which means that they have an ability to see and attach it and also have an ability to see and modify all the permissions for this volume. The variety of actions that can be granted by ACL is the following:

‘ro-attach’ action is attach the volume in Read/Only mode;
‘rw-attach’ action is attach the volume in Read/Write mode (in Read/Only mode if the volume is in ‘attached’ status);
‘view-permissions’ action is view permissions of the volume;
‘edit-permissions’ action is edit permissions of the volume;
‘multi-rw-attach’ is multiple attach in R/W mode

and this may be extended by such actions as transfer, backup, snapshot, clone, delete, edit metadata, view metadata, etc.

What features are brought up by ACL?

The owner of the volume and the administrators always have the full access.
The owner, the administrators and the users with granted ‘view-permissions’ action can read the permissions of the volume.
The owner, the administrators and the users with granted ‘edit-permissions’ action can edit the permissions of the volume.
The owner and the administrators can give the volume access permission to a single user, a group of users, all users, all projects.
The user can check his own access permission to a specific volume.
The permission of the owner and the administrators can be modified by administrators only.

Implementation

VolumeACLPermission table with columns:

id - the primary key of the row;
volume_id - indicates volume's ID;
entity_id - indicates an user or group ID whom the permission affects or “*” keyword for everyone;
entity_type - "user" means that entity_id is an user ID; "group" means that entity_id is a group ID (keystone v3 is able to deal with groups https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/v3/groups.py); "project" - project ID;
access - a json with mapping actions to permissions (granted action or not)
for the following actions:

“ro-attach”;
"rw-attach";
“multi-rw-attach";
"view-permissions";
"edit-permissions";
“transfer";
"backup";
 "snapshot";
 "clone";
 "delete";
 "edit-metadata";
 "view-metadata";
 etc.

An "access" json would be of a list type.
There is an example:
access =
[
    "ro-attach",
    "rw-attach"
]

# check if ‘ro-attach’ is granted
is_ro_attached = "ro-attach" in access

# allow access with ‘ro-attach’ permission
access.append(‘ro-attach’)

# reject access with ‘ro-attach’ permission
filter(lambda x: x != 'ro-attach', access)

# aggregate 2 accesses: access and access2
list(set(access) & set(access2))

Addressed by: https://review.openstack.org/60522
    Add Volume ACL Permissions: Keystone backend