Difference between revisions of "Manila/design/access groups"
(→How it works in different situations) |
|||
| Line 1: | Line 1: | ||
== Applying Access Rules == | == Applying Access Rules == | ||
=== Current approach === | === Current approach === | ||
| − | Today we use "manila allow-access" and "manila deny-access" cli command, to allow and deny "one" ip address/user/cert | + | 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 | In situation, when we want a "share" to be accessible by | ||
* a subnet OR | * a subnet OR | ||
* a set of IP addresses together OR | * a set of IP addresses together OR | ||
* a set users together | * a set users together | ||
| − | we have to execute allow-access for each combination of (IP address, share) '''one by one'''!! | + | 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 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 n^2 operations from user side. | ||
''That's cumbersome hence access-groups were proposed'' | ''That's cumbersome hence access-groups were proposed'' | ||
=== Requirement === | === Requirement === | ||
| − | Requirement is to have a mechanism, by which a set of | + | 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 | + | 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".''' | There comes the idea of '''"manila access-groups".''' | ||
=== Manila Access Groups === | === Manila Access Groups === | ||
| − | A new object named | + | A new object named 'access_group', can be created by user. Each 'access_group' contains, a bunch of homogeneous 'access_entries'. |
| − | Homogeneous here means | + | Homogeneous here means, 'entries of same access_type & access_level(in case access_type is 'user'))'. Each 'access_entry' represents, |
| − | either one | + | either one ip-address or one username. Bunch of access entries, associated to an "access-group", can be "allowed or denied" access, |
to a share in one go. | 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, | + | '''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 === | === Challenges === | ||
| − | * With new proposal, a set of access-rules can be applied together using "access-group". Earlier "allow-access/deny-access" api | + | * With new proposal, a set of access-rules can be applied together using "access-group". Earlier "allow-access/deny-access" api worked on individual access rule. |
| − | So | + | So, that can interfere and allow/deny any access, without any knowledge of access-group api. This has to be understood and resolved. |
| + | |||
* A parallel api interface, serving same purpose, but in different granularity, causes redundancy in database and information. | * 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. | * 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' newer version yet, then 'access-rules' will be sent to driver one by one only. | * If backend driver doesn't implement 'update_access' newer version yet, then 'access-rules' will be sent to driver one by one only. | ||
Though 'access-group' feature will allow user, to request access, to set of ip addresses, in one go, still backend will work on access-rules individually. | Though 'access-group' feature will allow user, to request access, to set of ip addresses, in one go, still backend will work on access-rules individually. | ||
| Line 57: | Line 60: | ||
[[File : Deny_access_group.png | center | 500px| deny access group flow]] | [[File : Deny_access_group.png | center | 500px| deny access group flow]] | ||
| − | + | == How it works in different situations == | |
'''Ques 1. Lets say a user requests allow-access-group for (share1, AG1)''' | '''Ques 1. Lets say a user requests allow-access-group for (share1, AG1)''' | ||
'''What if the share is already mapped to another access_group/access_rule.''' | '''What if the share is already mapped to another access_group/access_rule.''' | ||
Revision as of 11:33, 1 April 2016
Contents
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 username. 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 worked on individual access rule.
So, that can interfere and allow/deny any access, without any knowledge of access-group api. This 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' newer version yet, then 'access-rules' will be sent to driver one by one only.
Though 'access-group' feature will allow user, to request access, to set of ip addresses, in one go, still backend will work on access-rules individually.
Proposed Object Relationships:-
Important Actions
| Sr No | Function | Command |
|---|---|---|
| 1 | Create Access Group | manila access-group-create [--access-level <access_level>] <name> <description> <access_type> |
| 2 | Add Access Group Entries in Access group | manila access-group-entry-create <access_to> <access_group_id> |
| 3 | Allow Access Group to a share | manila access-group-allow <share> <access_group_id> |
| 4 | Deny Access Group to a share | manila access-group-deny <share> <access_group_id> |
Flow diagram
Allow Access Group
.png)
Deny Access Group
How it works in different situations
Ques 1. Lets say a user requests allow-access-group for (share1, AG1) What if the share is already mapped to another access_group/access_rule.
Ans: Nothing, set of access_rules for AG1, will be applied on share, using 'add_rule' field of 'update_access' helper function.
Ques 2. lets say 'share1' has an already applied access rule i.e ( user ,admin, rw). Now, 'AG1' contains (user, admin, ro). A request comes as 'allow_access_group(share1, AG1)'. share1 is asked to map with AG1, what should happen?
What if the already applied rules are redundant to AG1's access rules. Note:- its a redundant rule, not contradictory, as rules with 'same access_type and access_to' are considered redundant..
Ans: Its same as case, if we apply two redundant rules, even without access-groups. We will get an exception, 'access rule for (user, admin) already exists' and we will proceed to examine, rest of the rules, in access_group. We need to deny this rule first "to change its level if required.
Ques 3. What if AG1 is made up of n rules, only one is redundant ?
Ans: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.
Ques 4. What if AG1 is made up of 'n' rules, an error reported from backend for one of the rules?
Ans: 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 5. What if access group is already mapped to other shares and this is a new mapping.
Ans: Simply, rules from the access-group will be applied on the requested share.
Ques 6. 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_group_mapping in db for (share1 -> AG1) and passes “only set of rules in AG1" to driver layer. req2 also creates a access_group_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 7. 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. access_status_message" field in "share_instances" table - does not show error messages for above mentioned exceptions. Note:- in last two cases(4,5), though we come out, but 'share_access_group_mapping' and 'many share_access_map' entries would have been created!!!
Ques 8. What is purpose of access_rules_status and access_status_message field in share_instances table?
Ans: access_status_message field, registers the error message, from the driver layer. if we get an error message back from driver, it gets registered in 'access_status_message' in 'share_instances' table. 'access_status_message' field in 'share_instances' table - does not register error messages for above mentioned exceptions in Ques7.
Ques 9. 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> 3) manila access-group-deny <share-id> <access-group-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 DB, we raise exception Not-Found and continue to next access_entry.
Ques 10. Lets say a share share1 is mapped to an access_group AG1. Now we delete one of access_rule of AG1 or we add an entry to mapped access_group AG1. What will happen?
Ans: any addition or deletion of access_entry to an access_group after being mapped, will trigger 'update_access' on the backend.
