Difference between revisions of "Manila/design/access groups"
(→Thinking impact of 2nd approach..) |
(→Thinking impact of 2nd approach..) |
||
Line 161: | Line 161: | ||
=== Thinking impact of 2nd approach.. === | === Thinking impact of 2nd approach.. === | ||
− | |||
* This approach is lighter and less amount of redundancy in database. | * This approach is lighter and less amount of redundancy in database. | ||
Line 167: | Line 166: | ||
so no further means, to deal with 'access-groups', independently OR after share deletion. | so no further means, to deal with 'access-groups', independently OR after share deletion. | ||
− | * | + | * Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'. |
− | + | Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation? | |
* Will we keep these new individual access_rule records without tag? | * Will we keep these new individual access_rule records without tag? | ||
− | * Will we give every record which is in share_access_map, a tag..so this individual rule will have new access_group_tag? | + | * Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag??? |
− | |||
− | Now, the next share share3 that inherits with -- | + | I think '''we can keep the new rule without tag.''' |
− | the next share share3 that inherits with -- | + | Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay. |
+ | But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share2' ,AG1) | ||
* If share is deleted the access-group existed/associated with is, will be considered deleted. | * If share is deleted the access-group existed/associated with is, will be considered deleted. | ||
* If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself. | * If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself. | ||
− | now, a 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules. | + | now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules. |
− | Now, access-group with 'AG1' tag - has got two separate set of access-rules, one that's coming from share1(2 rules) | + | Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members. |
− | + | * one that's coming from share1(2 rules) | |
− | If a share3 is asking for rules same as tag AG1 what rules will be applied on it? That | + | * other that's coming from share2(3 rules). |
+ | Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it? | ||
+ | That needs to be decided in this approach. | ||
Actually | Actually | ||
'''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.''' | '''A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.''' |
Revision as of 05:57, 5 April 2016
Contents
Applying Access Rules
Current approach
Today we use "manila allow-access" and "manila deny-access" cli command, to allow and deny, "one" ip address/user/cert 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 combination of (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, by which 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 of ip addresses', 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_group', can be created by user. Each 'access_group' contains, a bunch of homogeneous 'access_entries'. Homogeneous here means, 'entries of same access_type & access_level(in case access_type is 'user'))'. Each 'access_entry' represents, either one ip-address or one username. Bunch of access entries, associated to an "access-group", can be "allowed or denied" access, to a share 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.
Challenges
- With new proposal, a set of access-rules can be applied together using "access-group". Earlier "allow-access/deny-access" api worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This has to be understood and resolved.
- A parallel api interface, serving same purpose, but in different granularity, causes redundancy in database and information.
- Sending a bunch of rules together to backend, if any one rule throws an exception, status of whole access-group will be errored.
- If backend driver doesn't implement 'update_access' newer version yet, then 'access-rules' will be sent to driver one by one only.
Though 'access-group' feature will allow user, to request access, to set of ip addresses, in one go, still backend will work on access-rules individually.
Proposed Object Relationships:-
Important Actions
Sr No | Function | Command |
---|---|---|
1 | Create Access Group | manila access-group-create [--access-level <access_level>] <name> <description> <access_type> |
2 | Add Access Group Entries in Access group | manila access-group-entry-create <access_to> <access_group_id> |
3 | Allow Access Group to a share | manila access-group-allow <share> <access_group_id> |
4 | Deny Access Group to a share | manila access-group-deny <share> <access_group_id> |
Flow diagram
Allow Access Group
Deny Access Group
How it works in different situations
Ques 1. Lets say a user requests allow-access-group for (share1, AG1) What if the share is already mapped to another access_group/access_rule.
Ans: Nothing, set of access_rules for AG1, will be applied on share, using 'add_rule' field of 'update_access' helper function.
Ques 2. lets say 'share1' has an already applied access rule i.e ( user ,admin, rw). Now, 'AG1' contains (user, admin, ro). A request comes as 'allow_access_group(share1, AG1)'. share1 is asked to map with AG1, what should happen?
What if the already applied rules are redundant to AG1's access rules. Note:- its a redundant rule, not contradictory, as rules with 'same access_type and access_to' are considered redundant..
Ans: Its same as case, if we apply two redundant rules, even without access-groups. We will get an exception, 'access rule for (user, admin) already exists' and we will proceed to examine, rest of the rules, in access_group. We need to deny this rule first "to change its level if required.
Ques 3. What if AG1 is made up of n rules, only one is redundant ?
Ans:If any one of the access_rule, from this access_group, is already applied on share(individually)... lets say due to 'allow-access' api. Then excluding that access_rule, rest of the rules, present in 'access_group' will be applied on share.
Ques 4. What if AG1 is made up of 'n' rules, an error reported from backend for one of the rules?
Ans: If there is an error, reported from backend, then error will be registered in share_instances table. 'access_rules_status' will go in 'error' state and 'access_status_message' will contain the descriptive message.
Ques 5. What if access group is already mapped to other shares and this is a new mapping.
Ans: Simply, rules from the access-group will be applied on the requested share.
Ques 6. Two compatible access-groups mapping request got out of order before reaching backend driver.
Lets say two api requests for two access_groups where two access groups's rules are compatible as below: Two api requests come in this order chronologically, req1 then req2, AG1 has (user, admin, rw), AG2 has (ip, 10.1.1.1, None) req1 = allow_access_group(share1, AG1), req2 = allow_access_group(share1, AG2) Let’s say these request reach driver layer, out of order, driver receives req2 then req1. What will happen in such case?
Ans: req1 creates a access_group_mapping in db for (share1 -> AG1) and passes “only set of rules in AG1" to driver layer. req2 also creates a access_group_mapping in db for (share1 -> AG2) and passes that “only set of rules in AG2" to driver layer. Driver layer gets req2 first, it will apply access_rules of req2 first and then access_rules from req1 will be applied on backend.
Ques 7. What happens if an exception is raised for one of the access-rules in access-group in api layer itself? Do we proceed for next rule or we come out ?
Ans: These are such exceptions which come like 1)if share status is not AVAILABLE >> we raise exception and come out 2)If share_access entry already exists for this share ? >> we raise exception but continue to consider next access_rule 3)if access_level value requested for is not a valid value >> we raise exception and come out 4)If share_instance is invalid one >> we raise exception and come out 5)if access_rules_status is not active >> we raise exception and come out
in all such cases we raise exception before rpc request is sent to driver layer. access_status_message" field in "share_instances" table - does not show error messages for above mentioned exceptions. Note:- in last two cases(4,5), though we come out, but 'share_access_group_mapping' and 'many share_access_map' entries would have been created!!!
Ques 8. What is purpose of access_rules_status and access_status_message field in share_instances table?
Ans: access_status_message field, registers the error message, from the driver layer. if we get an error message back from driver, it gets registered in 'access_status_message' in 'share_instances' table. 'access_status_message' field in 'share_instances' table - does not register error messages for above mentioned exceptions in Ques7.
Ques 9. Lets say an access-group that contains 4 access_rules, that is applied on a share1. now these 4 access_rules have got their entries created in share_access_map too. What is someone deleted/denies the access rule individually ? that is sequence is like 1) manila access-group-allow <share-id> <access-group-id> 2) manila access-deny <share> <id> 3) manila access-group-deny <share-id> <access-group-id> Now some rules of this access-group are denied individually .. when we go to 'deny-access-group' what will happen?
Ans: For each of 4 rules, if anyone is not present in the DB, we raise exception Not-Found and continue to next access_entry.
Ques 10. Lets say a share share1 is mapped to an access_group AG1. Now we delete one of access_rule of AG1 or we add an entry to mapped access_group AG1. What will happen?
Ans: any addition or deletion of access_entry to an access_group after being mapped, will trigger 'update_access' on the backend.
Alternative Approach
This approach suggests to tag/group share_access_map records by using a new field access_group_tag. Here we do not create a separate entity access_group and access_group_entries. Instead by using a string type tag with share_access_map records, we group a few entries together.
For first share that wants to allow a group of ip addresses/user the access. cli call will be like...
manila access-allow %some_share% ip 1.1.1.1,2.2.2.2, 3.3.3.3 --tag %tag_name_1%
After that any share that wants similar access will do either:
manila access-inherit %some_new_share% --by-share %some_source_share%
Or
manila access-inherit %some_new_share% --by-tag %tag%
Thinking impact of 2nd approach..
- This approach is lighter and less amount of redundancy in database.
- Access-group, being dynamic entity in 2nd approach/a no separate entity, which has its 'existence scope' same as the share its associated with,
so no further means, to deal with 'access-groups', independently OR after share deletion.
- Lets say, 'share1' is applied with set of access-rules tagged as 'AG1'. if 'share2' inherits all access_rules from 'share1'.
Now 'share1' adds a rule by old 'allow-access' api. How will we tackle such situation?
* Will we keep these new individual access_rule records without tag? * Will we give every record which is in 'share_access_map' table, a tag..so this individual rule will have new access_group_tag???
I think we can keep the new rule without tag. Now, the next share 'share3' that inherits with --share from 'share1', will get all rules inclusive (share1, with tag) and (share1, without tag). okay. But, if the next share 'share3' that inherits with --tag 'AG1' will get rules which is with ('share2' ,AG1)
- If share is deleted the access-group existed/associated with is, will be considered deleted.
- If a share1 has allowed access to 3 ip addresses tagged with 'AG1', now another 'share2' inherited all 3 rules with 'AG1' tag itself.
now, a old 'deny-access' request comes, to delete one of the rule with share1 from these 3 rules. Now, access-group with 'AG1' tag - has got two separate set of access-rules, defining its members.
- one that's coming from share1(2 rules)
- other that's coming from share2(3 rules).
Now, If a 'share3' is asking for rules same as tag 'AG1', what rules will be applied on it? That needs to be decided in this approach. Actually A group/A tag can not have a static definition (set of rules) among all these allow/deny of different sorts.