Difference between revisions of "Manila/design/access groups"
(→* Create Access Group) |
(→Action Flow) |
||
Line 35: | Line 35: | ||
== Action Flow == | == Action Flow == | ||
− | === | + | === Create Access Group === |
Create an access group:- | Create an access group:- | ||
stack@controller:~/devstack$ manila help access-group-create | stack@controller:~/devstack$ manila help access-group-create | ||
Line 54: | Line 54: | ||
manila access-group-create "AG2" "2nd" "user" --access_level "rw" | 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 | stack@controller:~/devstack$ manila help access-group-entry-create | ||
usage: manila access-group-entry-create <access_to> <access_group_id> | usage: manila access-group-entry-create <access_to> <access_group_id> | ||
Line 66: | Line 66: | ||
manila --debug access-group-entry-create "demou" b81aafa9-9a46-4cf6-9d70-6c3d97442cfb | manila --debug access-group-entry-create "demou" b81aafa9-9a46-4cf6-9d70-6c3d97442cfb | ||
− | === | + | === Allow Access Group to a share === |
Associating an access_group with a share - Allow access(cli) | Associating an access_group with a share - Allow access(cli) | ||
stack@controller:~/devstack$ manila help access-group-allow | stack@controller:~/devstack$ manila help access-group-allow | ||
Line 80: | Line 80: | ||
manila --debug access-group-allow 0244bc55-ba39-4977-879d-96f8a5d4894c b81aafa9-9a46-4cf6-9d70-6c3d97442cfb | manila --debug access-group-allow 0244bc55-ba39-4977-879d-96f8a5d4894c b81aafa9-9a46-4cf6-9d70-6c3d97442cfb | ||
− | 1)Check if share_access_group_mapping | + | ===== Steps ===== |
+ | 1)Check if share_access_group_mapping doesn't exist for given share_id and access_group_id, then a record will be added to “share_access_group_mapping” table. | ||
+ | else the obtained record will be returned. End. | ||
2)For each 'access_group_entry' in 'access_group_entries' for this access_group: | 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) | + | 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. | + | create a new "share_access_map" record - obtain it. |
− | append a list of such access rules. | + | 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. | 3)Pass 'access_rules_list' to be applied as a "bunch", to each of share_instance, associated with share. | ||
− | + | ===== FlowChart ===== | |
− | + | [[File:: | Allow_access_group.png | center | Allow access group flow]] | |
− | + | ===== Design Decisions ===== | |
− | + | # 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??? | 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. | No, set of access_rules for this access_group only, will be applied on share. | ||
Line 99: | Line 101: | ||
then excluding that access_rule, rest of the rules present in access_group will be applied on share. | 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. | Simply, rules from the access-group will be applied on the share. | ||
− | |||
Need to check this (Pending)!!! | Need to check this (Pending)!!! | ||
Line 117: | Line 118: | ||
) | ) | ||
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. | 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. | ||
− | |||
=== * Deny Access Group to a share === | === * Deny Access Group to a share === | ||
Line 140: | Line 140: | ||
Flowchart for the process:- | Flowchart for the process:- | ||
− | + | <gallery> | |
+ | Allow_access_group.png|Caption1 | ||
+ | </gallery> |
Revision as of 09:06, 31 March 2016
- Example.jpg
Caption1
- Example.jpg
Caption2
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
Steps
1)Check if share_access_group_mapping doesn't exist for given share_id and access_group_id, then a record will be added to “share_access_group_mapping” table.
else the obtained record will be returned. End.
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
[[File:: | Allow_access_group.png | center | Allow access group flow]]
Design Decisions
- 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:-