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

Revision as of 09:38, 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>

Steps

1)Check if share_access_group_mapping doesn't exist for given share_id and access_group_id, then a record will be added to “share_access_group_mapping” table.

  else the obtained record will be returned. End.

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

[[File : | allow_access_group.png | center | Allow access group flow]]

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

If a contradictory rule is already applied, 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.

* Deny Access Group to a share

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

Flowchart for the process:- [[File : | deny_access_group.png | center | deny access group flow]]

@@ Line 1: / Line 1: @@
-<gallery>
+                                                                                                                       = Manila Access Groups =
-Example.jpg|Caption1
+== Applying Access Rules ==
-Example.jpg|Caption2
+=== Current approach ===
-</gallery>
+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
-== Current approach for access rules to a share==
+* a subnet OR
-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
+* a set of ip addresses together OR
-to a subnet OR
+* a set users together
-a set of ip addresses together OR
+we have to execute allow-access for each (ip address, share) one by one!!
-a set users together
+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,
-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.''
-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".'''
-=== Requirement ===
+=== Manila Access Groups ===
-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.
+A new object named "access_groups" will be created by user. Each "access_group" represents a bunch of homogeneous "access_rules/access_entries".
-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.
+(homogeneous here means rules of same "access_type & access_level")
-=== Manila Access groups ===
+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.
-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 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.
-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,
-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.''
-instead of allowing each ip-address/user one at a time.
 === Challenges ===
@@ Line 37: / Line 36: @@
 === Create Access Group ===
 Create an access group:-
-stack@controller:~/devstack$ manila help  access-group-create
+manila access-group-create [--access-level <access_level>] <name> <description> <access_type>
-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
 ===== Steps =====
@@ Line 92: / Line 57: @@
 ===== FlowChart =====
-[[File:: | Allow_access_group.png | center | Allow access group flow]]
+[[File : | allow_access_group.png | center | Allow access group flow]]
 ===== Design Decisions =====
-# What if The share is already mapped to another access_group already ??
+'''#Ques: What if the share is already mapped to another access_group/access_rules(individual) already,'''
-All rules for this share id - consolidating the ones from earlier mappings and this new one will be reapplied???
+Will all rules for this share id - consolidating the ones from earlier mappings and this new one, be reapplied?
-No, set of access_rules for this access_group only, will be applied on share.
+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.
-# What if access group is already mapped to other shares and this is a new mapping.
+===== Case2 Contradictory Rules =====
+If a contradictory rule is already applied, 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.
-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.
+Flowchart for the process:-
-Action = deny_access_group
+[[File : | deny_access_group.png | center | deny access group flow]]
-JSON Request
-{
- "deny_access_group":
-      {
-           "access_group":  <Access-group-uuid>,
-     }
- }
- Flowchart for the process:-
-<gallery>
-Allow_access_group.png|Caption1
-</gallery>