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

Revision as of 10:00, 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

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>

Allow Access Group to a share

Associating an access_group with a share - Allow access(cli) usage: manila access-group-allow <share> <access_group_id>

FlowChart

* Deny Access Group to a share

usage: 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, 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

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?

I think its same as case if we apply two contradictory rules even without access-groups- we will get an error access rule for user admin is already applied. We need to deny it first to change it. 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 share.

# Ques: Two compatible access-groups mapping request got out of order before reaching backend driver. Two api requests for two access_groups where two access rules are compatible, came such as AG1 has (user, admin, rw) AG2 has (ip, 10.1.1.1, None)

2 Api requests come in this order allow_access(share1, AG1) – Req1 allow_access(share1, AG2) – Req2

let’s say these request reach driver, out of order, that is backend driver receives, first Req2 then Req1.

https://etherpad.openstack.org/p/manila-access-groups-api-proposal line 324 says

• • NOTE** the backend driver will always have to update the export rules to whatever the current state reflected in the database may be, to avoid race conditions with changes to the access group. For example, if someone makes two requests to the api and the messages arrive out of order to the driver, the end state of the first message will incorperate both changes and the second message will be a noop

That is It says  :- Req2 -> tells the driver to update export rules as per current state in DB. Current state in DB is -> for share1 -> add two rules for AG1 and AG2 both. Req1 -> for driver is noop

My Doubt :- What I see is Req1 creates a access_mapping in db for share1 -> AG1 and passes that “only new” set of rules to driver layer.

Currently driver doesn’t work on current state of DB

   def allow_access(self, context, share_instance_id, access_rules):            
      """Allow access to some share instance."""            

add_rules = [self.db.share_access_get(context, rule_id)

                          for rule_id in access_rules] >>            
           

2. Adding/Deleting of several access rules - 'access_rules' contains

       all access_rules, 'add_rules' and 'delete_rules' contain rules which            
       should be added/deleted.Driver can ignore rules in 'access_rules' and            
       apply only rules from 'add_rules' and 'delete_rules'.            

Hence driver will only apply rules from req1 only. My understanding is Req1 driver stage won’t apply req2’s rules on share.

Case3:- Access group contains multiple entries, where backend could apply only a few successfully, a few could not be applied.

Ques3: A share allow_access(share1, AG1)

AG1 has 3 access rule entries

[{ip, 1.1.1.1, none}, {ip, 2.2.2.2, None}, {ip, 3.3.3.3, None}]

Changes made to share_access_group_mapping table.

Backend could not apply 3rd rule successfully{ip, 3.3.3.3, None}

Result status will be marked in access_rules_status field, access_status_message will show the reason.

Case 4: if there are 4 rules to be applied as part of access_group, lets say 1 rule is redundant - does it try for 3 others ??

or a exception comes and it doesnt try further ?
These are such exceptions which come like
1)if share status is not AVAILABLE 
2)If share_access entry already exists for this share ?
3)if access_level value requested for is not a valid value
4)If share_instance is invalid one
5)if access_rules_status is not active
in all such cases we raise exception which is coming before rpc request is sent to driver layer.

Now need to decide

" access_status_message" field in "share_instances" table - will it express such messages for such exceptions?

OR 

will it express the concern if driver has in applying those rules?e ex If yes, in that case, it has to get a message back from driver, to know which rules it could not apply and why ? How to get that status back from driver (Need to check)

Case5:- What if an access-group that contains 4 access_rules 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 
1) manila access-group-allow <share-id> <access-group-id>
then 
2)manila access-deny <share> <id>

Now some rules of this access-group are denied individually .. when we go to deny it