Manila/design/access groups
- Example.jpg
Caption1
- Example.jpg
Caption2
Contents
Today we use "manila allow-access" and "manila deny-access" cli to allow and ip address/user the access to a particular share. In case we want a share to be accessible to a subnet OR a set of ip addresses together OR a set users together we have to allow each ip address separately one by one!! If we want to allow a same set of 'n' ip addresses, for each of 'n' shares, then n number of ip addresses will require n iterations for each share that's n^2 operations from user side.
That's cumbersome hence access-groups were proposed.
Requirement
Requirement is to have a mechanism so that a set of ip addresses can be considered as one entity, can be allowed the access to a share together. Henceforth, the same set can be allowed access to any other share in one single request from user. There comes the idea of manila access-groups.
Manila Access groups
A new object named "access_groups" will be created by user. Each "access_group" represents a bunch of "access_rules" of same "access_type & access_level". Bunch of access rules can be either a "set of ip addresses or can be set of users", to be allowed or denied in a go.
Access Group contains a set of "homogeneous access_entries". Each "access_entry" holds either one "ip-address" or one "user-name" at a time. Feature requirement is to provide a mechanism, to allow the access to a share for "a group of ip addresses/users", in one go, instead of allowing each ip-address/user one at a time.
Challenges
A set of rules applied in a bunch using access-groups. Earlier "allow-access/deny-access" api works on individual access rules. So it can interfere and allow/deny any access without any knowledge of access-group. That has to be taken care of.
A parallel interface to serve same purpose but in different granularity, causes redundancy in database and information.
Object Relationships:-
Action Flow
* Create Access Group
Create an access group:- stack@controller:~/devstack$ manila help access-group-create usage: manila access-group-create [--access-level <access_level>] <name> <description> <access_type>
Add a new access group.
Positional arguments:
<name> access group name. <description> access group description. <access_type> access type of access group.
Optional arguments:
--access-level <access_level>, --access_level <access_level>
Share access level ("rw" and "ro" access levels are
supported). Defaults to rw.
e.g. manila access-group-create "AG2" "2nd" "user" --access_level "rw"
* Add Access Group Entries in Access group
stack@controller:~/devstack$ manila help access-group-entry-create usage: manila access-group-entry-create <access_to> <access_group_id>
Add a new access group entry.
Positional arguments:
<access_to> Value that defines access. <access_group_id> Access Group ID.
manila --debug access-group-entry-create "demou" b81aafa9-9a46-4cf6-9d70-6c3d97442cfb
Associating an access_group with a share - Allow access(cli) stack@controller:~/devstack$ manila help access-group-allow usage: manila access-group-allow <share> <access_group_id>
Map access group to the share.
Positional arguments:
<share> ID of the NAS share to modify. <access_group_id> ID of the access_group.
stack@controller:~/devstack$
manila --debug access-group-allow 0244bc55-ba39-4977-879d-96f8a5d4894c b81aafa9-9a46-4cf6-9d70-6c3d97442cfb
1)Check if share_access_group_mapping doesnt exist for given share_id and access_group_id. , then an entry will be added to“share_access_group_mapping” table.
2)For each 'access_group_entry' in 'access_group_entries' for this access_group: check sanity of each access_group_entry (if its already applied through access-allow api separately, OR if its a invalid access_level etc raise exception in such cases, continue the loop to next entry) create a new "share_access_map" record - obtain it. append a list of such access rules.
3)Pass 'access_rules_list' to be applied as a "bunch", to each of share_instance, associated with share.
Flowchart link:- https://wiki.openstack.org/w/images/8/85/Allow_access_group.png
- What if The share is already mapped to another access_group already ??
All rules for this share id - consolidating the ones from earlier mappings and this new one will be reapplied??? No, set of access_rules for this access_group only, will be applied on share. If any access_rule from this access_group, is already applied on share(individually), due to access_allow api.. then excluding that access_rule, rest of the rules present in access_group will be applied on share.
- What if access group is already mapped to other shares and this is a new mapping.
Simply, rules from the access-group will be applied on the share.
Need to check this (Pending)!!!
result_rules = [entries in access_group_id AG1] union [set of entries in share_access_map table for this share_id] will be sent to driver like this.
self.driver.update_access(
context,
share_instance,
result_rules,>>>>>>>>>>>>>>>>>> all rules
add_rules=add_rules,>>>> rules present only in AG1
delete_rules=delete_rules,
share_server=share_server
)
If there is an error in applying rules, due to any reason, “access_rule_status” for share will reflect that with a descriptive error message.
stack@controller:~/devstack$ manila help access-group-deny usage: manila access-group-deny <share> <access_group_id> Unmap access group to the share. Positional arguments:
<share> Name or ID of the NAS share to modify. <access_group_id> ID of the access group to be unmapped.
stack@controller:~/devstack$ manila --debug access-group-deny 0244bc55-ba39-4977-879d-96f8a5d4894c b81aafa9-9a46-4cf6-9d70-6c3d97442cfb
If it’s found in share_access_mapping, it will delete the mapping - will obtain all rules in the given access-group - and call update_access to delete these rules. Action = deny_access_group JSON Request {
"deny_access_group":
{
"access_group": <Access-group-uuid>,
}
}
Flowchart for the process:-
