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

Revision as of 08:51, 31 March 2016

• Example.jpg

  Caption1

• Example.jpg

  Caption2

Current approach for access rules to a share

Today we use "manila allow-access" and "manila deny-access" cli to allow and ip address/user the access to a particular share. In case we want a share to be accessible to a subnet OR a set of ip addresses together OR a set users together we have to allow each ip address separately one by one!! If we want to allow a same set of 'n' ip addresses, for each of 'n' shares, then n number of ip addresses will require n iterations for each share 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, 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 "access_rules" of same "access_type & access_level". Bunch of access rules can be either a "set of ip addresses or can be set of users", to be allowed or denied in a go.

Access Group contains a set of "homogeneous access_entries". Each "access_entry" holds either one "ip-address" or one "user-name" at a time. 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:- stack@controller:~/devstack$ manila help access-group-create usage: manila access-group-create [--access-level <access_level>]

                                 <name> <description> <access_type>

Add a new access group.

Positional arguments:

 <name>                access group name.
 <description>         access group description.
 <access_type>         access type of access group.

Optional arguments:

 --access-level <access_level>, --access_level <access_level>
                       Share access level ("rw" and "ro" access levels are
                       supported). Defaults to rw.

e.g. manila access-group-create "AG2" "2nd" "user" --access_level "rw"

* Add Access Group Entries in Access group

stack@controller:~/devstack$ manila help access-group-entry-create usage: manila access-group-entry-create <access_to> <access_group_id>

Add a new access group entry.

Positional arguments:

 <access_to>        Value that defines access.
 <access_group_id>  Access Group ID.

manila --debug access-group-entry-create "demou" b81aafa9-9a46-4cf6-9d70-6c3d97442cfb

* Allow Access Group to a share

Associating an access_group with a share - Allow access(cli) stack@controller:~/devstack$ manila help access-group-allow usage: manila access-group-allow <share> <access_group_id>

Map access group to the share.

Positional arguments:

 <share>            ID of the NAS share to modify.
 <access_group_id>  ID of the access_group.

stack@controller:~/devstack$

manila --debug access-group-allow 0244bc55-ba39-4977-879d-96f8a5d4894c b81aafa9-9a46-4cf6-9d70-6c3d97442cfb

1)Check if share_access_group_mapping doesnt exist for given share_id and access_group_id. , then an entry will be added to“share_access_group_mapping” table.

2)For each 'access_group_entry' in 'access_group_entries' for this access_group: check sanity of each access_group_entry (if its already applied through access-allow api separately, OR if its a invalid access_level etc raise exception in such cases, continue the loop to next entry) create a new "share_access_map" record - obtain it. append a list of such access rules.

3)Pass 'access_rules_list' to be applied as a "bunch", to each of share_instance, associated with share.

Flowchart link:- https://wiki.openstack.org/w/images/8/85/Allow_access_group.png

• • What if The share is already mapped to another access_group already ??

All rules for this share id - consolidating the ones from earlier mappings and this new one will be reapplied??? No, set of access_rules for this access_group only, will be applied on share. 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.

• • 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.

Need to check this (Pending)!!!

result_rules = [entries in access_group_id AG1] union [set of entries in share_access_map table for this share_id] will be sent to driver like this.

self.driver.update_access(

                   context,            
                   share_instance,            
                   result_rules,>>>>>>>>>>>>>>>>>> all rules            
                   add_rules=add_rules,>>>> rules present only in AG1            
                   delete_rules=delete_rules,            
                   share_server=share_server            
               )            

If there is an error in applying rules, due to any reason, “access_rule_status” for share will reflect that with a descriptive error message.

* Deny Access Group to a share

stack@controller:~/devstack$ manila help access-group-deny usage: manila access-group-deny <share> <access_group_id> Unmap access group to the share. Positional arguments:

 <share>            Name or ID of the NAS share to modify.
 <access_group_id>  ID of the access group to be unmapped.

stack@controller:~/devstack$ manila --debug access-group-deny 0244bc55-ba39-4977-879d-96f8a5d4894c b81aafa9-9a46-4cf6-9d70-6c3d97442cfb

If it’s found in share_access_mapping, it will delete the mapping - will obtain all rules in the given access-group - and call update_access to delete these rules. Action = deny_access_group JSON Request {

"deny_access_group": 
     {            
          "access_group":  <Access-group-uuid>, 
    }            
}            
           
Flowchart for the process:-

https://wiki.openstack.org/wiki/File:Deny_access_group.png