Difference between revisions of "Manila/design/access groups"
(→Action Flow) |
|||
Line 1: | Line 1: | ||
− | + | = Manila Access Groups = | |
− | + | == Applying Access Rules == | |
− | + | === Current approach === | |
− | + | Today we use "manila allow-access" and "manila deny-access" cli to allow and deny ip address/user, the access, to a particular share. In situation, when we want a share to be accessible by | |
− | == Current approach | + | * a subnet OR |
− | Today we use "manila allow-access" and "manila deny-access" cli to allow and ip address/user the access to a particular share. In | + | * a set of ip addresses together OR |
− | + | * a set users together | |
− | a set of ip addresses together OR | + | we have to execute allow-access for each (ip address, share) one by one!! |
− | a set users together | + | That is, If we want to allow a same set of 'n' ip addresses, for each of 'n' shares, then it requires n iterations for each of n shares, |
− | we have to allow each ip address | ||
− | If we want to allow a same set of 'n' ip addresses, for each of 'n' shares, then | ||
that's n^2 operations from user side. | 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 i.e. 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 homogeneous "access_rules/access_entries". | |
− | + | (homogeneous here means rules of same "access_type & access_level") | |
− | + | Access Group contains a set of homogeneous access_entries. Each "access_entry" holds/represents, either one "ip-address" or one "user-name" at a time. | |
− | + | Bunch of access rules associated to an access-group, can be "Either a set of ip addresses OR a set of users", that requires to be "allowed or denied" in a go. | |
− | Bunch of access rules can be | ||
− | + | ''Feature requirement is, to provide a mechanism, to allow the access to a share for "a group of ip addresses/users", in one go, | |
− | 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.'' |
− | instead of allowing each ip-address/user one at a time. | ||
=== Challenges === | === Challenges === | ||
Line 37: | Line 36: | ||
=== Create Access Group === | === Create Access Group === | ||
Create an access group:- | Create an access group:- | ||
− | + | manila access-group-create [--access-level <access_level>] <name> <description> <access_type> | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=== Add Access Group Entries in Access group === | === Add Access Group Entries in Access group === | ||
− | |||
usage: manila access-group-entry-create <access_to> <access_group_id> | usage: manila access-group-entry-create <access_to> <access_group_id> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=== Allow Access Group to a share === | === 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) | ||
− | |||
usage: manila access-group-allow <share> <access_group_id> | usage: manila access-group-allow <share> <access_group_id> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
===== Steps ===== | ===== Steps ===== | ||
Line 92: | Line 57: | ||
===== FlowChart ===== | ===== FlowChart ===== | ||
− | [[File | + | [[File : | allow_access_group.png | center | Allow access group flow]] |
===== Design Decisions ===== | ===== Design Decisions ===== | ||
− | # What if | + | '''#Ques: What if the share is already mapped to another access_group/access_rules(individual) already,''' |
− | + | Will all rules for this share id - consolidating the ones from earlier mappings and this new one, be reapplied? | |
− | No, set of access_rules for this access_group only, will be applied on share. | + | |
+ | Ans: No, set of access_rules for this access_group only, will be applied on share. | ||
+ | ===== Case1 Redundant Rules ===== | ||
If any access_rule from this access_group, is already applied on share(individually), due to access_allow api.. | 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. | 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. | + | ===== Case2 Contradictory Rules ===== |
+ | If a contradictory rule is already applied, there is an error reported from backend, then error will be registered in share_instance table. | ||
+ | access_rules_status will go in error state and access_status_message will contain the descriptive message. | ||
+ | |||
+ | '''# 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. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=== * Deny Access Group to a share === | === * Deny Access Group to a share === | ||
− | |||
usage: manila access-group-deny <share> <access_group_id> | usage: manila access-group-deny <share> <access_group_id> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | Flowchart for the process:- | |
− | + | [[File : | deny_access_group.png | center | deny access group flow]] | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |
Revision as of 09:38, 31 March 2016
= Manila Access Groups =
Contents
Applying Access Rules
Current approach
Today we use "manila allow-access" and "manila deny-access" cli to allow and deny ip address/user, the access, to a particular share. In situation, when we want a share to be accessible by
- a subnet OR
- a set of ip addresses together OR
- a set users together
we have to execute allow-access for each (ip address, share) one by one!! That is, If we want to allow a same set of 'n' ip addresses, for each of 'n' shares, then it requires n iterations for each of n shares, 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 i.e. 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 homogeneous "access_rules/access_entries". (homogeneous here means rules of same "access_type & access_level")
Access Group contains a set of homogeneous access_entries. Each "access_entry" holds/represents, either one "ip-address" or one "user-name" at a time. Bunch of access rules associated to an access-group, can be "Either a set of ip addresses OR a set of users", that requires to be "allowed or denied" in a go.
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:- manila access-group-create [--access-level <access_level>] <name> <description> <access_type>
Add Access Group Entries in Access group
usage: manila access-group-entry-create <access_to> <access_group_id>
Associating an access_group with a share - Allow access(cli) usage: manila access-group-allow <share> <access_group_id>
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
#Ques: What if the share is already mapped to another access_group/access_rules(individual) already, Will all rules for this share id - consolidating the ones from earlier mappings and this new one, be reapplied?
Ans: No, set of access_rules for this access_group only, will be applied on share.
Case1 Redundant Rules
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.
Case2 Contradictory Rules
If a contradictory rule is already applied, there is an error reported from backend, then error will be registered in share_instance table. access_rules_status will go in error state and access_status_message will contain the descriptive message.
# 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.
usage: manila access-group-deny <share> <access_group_id>
Flowchart for the process:- [[File : | deny_access_group.png | center | deny access group flow]]