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

Revision as of 10:31, 31 March 2016

                                                                                                                      = 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

• 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

manila access-group-create [--access-level <access_level>] <name> <description> <access_type>

Add Access Group Entries in Access group

manila access-group-entry-create <access_to> <access_group_id>

Allow Access Group to a share

manila access-group-allow <share> <access_group_id>

FlowChart

* Deny Access Group to a share

manila access-group-deny <share> <access_group_id>

Flowchart

Design Decisions

#Ques: What if the share is already mapped to another access_group/access_rules(individual) already, Ans: Set of access_rules for this access_group, will be applied on share.

Case1: Redundant rules, lets say share1 has a access rule already applied to it as Access entry for Share1 ->( user ,admin, rw) (in share_access_map) Now an AG1 with an (user, admin, ro) is created. API request comes as allow_access(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".

What if AG1 is made up of "n" rules, only one is redundant?Italic text 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.

What if there is an error reported from backend AG1 is made up of n rules, only one is redundant?Italic text If 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 requested share.

#Ques: Two compatible access-groups mapping request got out of order before reaching backend driver. e.g two api requests for two access_groups where two access rules are compatible,

Two access-groups are: AG1 has (user, admin, rw), AG2 has (ip, 10.1.1.1, None)

Two api requests come in this order chronologically, allow_access(share1, AG1) – Req1 allow_access(share1, AG2) – Req2

let’s say these request reach driver layer, out of order, that is backend driver receives, first Req2 then Req1. What will happen in such case ?

Ans: Req1 creates a access_mapping in db for (share1 -> AG1) and passes “only new set of rules in AG1" to driver layer. Req2 also creates a access_mapping in db for (share1 -> AG2) and passes that “only new 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? 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 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 come out
4)If share_instance is invalid one >> we come out 
5)if access_rules_status is not active >> we come out 
in all such cases we raise exception which is coming before rpc request is sent to driver layer.

" access_status_message" field in "share_instances" table - it does not express error messages for such exceptions. " access_status_message" field registers the error message from the driver layer. in case we gets an error message back from driver, which tells rules it could not apply and why ? and registers message in share_instance table.

Ques: Lets say an access-group that contains 4 access_rules, that is applied on a share 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 NotFound and continue to next access_entry.