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

Revision as of 06:05, 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 functionality, then rules will be sent to driver one by one only. Though access-group will allow user to

 request access to bunch 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 ====

Design Decisions

#Ques: Lets say , a user requests allow-access-group for (share1, AG1). What if the "share" is already mapped to another access_group/access_rule(individual), Ans: Nothing, set of access_rules for AG1, will be applied on share using add_rule field of update_access().

Ques: What if the already applied rules are redundant to AG1 ? lets say share1 has a access rule already applied to it as Share1 ->( user ,admin, rw) (in share_access_map) Now an AG1 contains an (user, admin, ro). API request comes as allow_access_group(share1, AG1). Share1 is asked to map with AG1, what should happen?

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 (this rule will be considered as applied already) and we will proceed to see rest of the rules in access_group. We need to deny this rule first "to change its level if reqd".

Ques: What if AG1 is made up of "n" rules, only one is redundant? 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 and share_access_group_mapping will be created

'Ques: What if AG1 is made up of "n" rules, an error reported from backend for one of the rules? 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: 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 requested share.

Ques: 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_mapping in db for (share1 -> AG1) and passes “only set of rules in AG1" to driver layer. req2 also creates a access_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: 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. in last two cases, share_access_group_mapping and many share_access_map entries would have been created!!!

Ques: What is purpose of access_rules_status and access_status_message field in share_instances table? " access_status_message" field registers the error message from the driver layer. " access_status_message" field in "share_instances" table - it does not show error messages for above mentioned exceptions. if we get an error message back from driver, it gets registered in share_instances table.

Ques: 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>
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 access_map, we raise exception Not-Found and continue to next access_entry.