Difference between revisions of "Manila/design/access groups"

Revision as of 10:23, 1 April 2016

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 "user-name". 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 works on individual access rules.

So it can interfere and allow/deny any access without any knowledge of access-group api. That 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

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) is already applied' 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.