Difference between revisions of "POC for QuotaManagement"
(→Example 3) |
(→Example 1) |
||
| Line 15: | Line 15: | ||
===== Example 1 ===== | ===== Example 1 ===== | ||
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. <br/> | Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session. <br/> | ||
| − | <ins>Scope | + | <ins>Scope</ins> <br/> |
ProjH <br/> | ProjH <br/> | ||
<ins>Roles (find role at each project level upto the leaf node)</ins> <br/> | <ins>Roles (find role at each project level upto the leaf node)</ins> <br/> | ||
Revision as of 11:08, 11 February 2014
Introduction
This Page explains the Proof of Concept for Quota Management in the Openstack Hierarchical Multitenancy setup.
Setup
Please see the following picture for an example Hierarchical Multitenancy setup.
Explanation
Authentication: Every user has to authenticate with keystone using a project scope. For example, userA can authenticate using the project scope as "ProjH.ProjA". The cloud admin can authenticate using any scope. When authenticated, the entire hierarchy is parsed starting from the scope project till the leaf node and construct the roles the user has at each level. See the following examples.
Example 1
Cloud Admin authenticates at "ProjH", keystone will send the following information (or token) for this session.
Scope
ProjH
Roles (find role at each project level upto the leaf node)
- ProjH, admin
- ProjH.ProjA, admin
- ProjH.ProjA.ProjA1, admin
- ProjH.ProjA.ProjA2, admin
- ProjH.ProjA.ProjA1.ProjA3, admin
- ProjH.ProjA.ProjA1.ProjA4, admin
- ProjH.ProjB, admin
- ProjH.ProjB.ProjB1, admin
- ProjH.ProjB.ProjB2, admin
- ProjH.ProjB.ProjB1.ProjB3, admin
- ProjH.ProjB.ProjB1.ProjB4, admin
Noteː For Cloud Admin, the entire Hierarchy of the Projects is not required (as he is the super admin and possess all the rights to do anything). But this can be useful to check the action requested by the admin with an hierarchy actually exists or not, without again contacting the Keystone again. For example, if admin wants to list the quotas for ProjH.ProjC, but by seeing the roles, he can be notified immediately that this hierarchy does not exist
Example 2
Cloud Admin authenticates at "ProjH.ProjA.ProjA1", keystone will send the following information (or token) for this session.
Scope
ProjH.ProjA.ProjA1
Roles (find role at each project level upto the leaf node)
̇̇̇̇̇̇̇̇̇̈* ProjH.ProjA.ProjA1, admin
- ProjH.ProjA.ProjA1.ProjA3, admin
- ProjH.ProjA.ProjA1.ProjA4, admin
̽
Example 3
User A authenticates at "ProjH.ProjA", keystone will send the following information (or token) for this session.
Scope
ProjH.ProjA
Roles (find role at each project level upto the leaf node)
- ProjH.ProjA, project-admin
- ProjH.ProjA.ProjA1, project-admin
- ProjH.ProjA.ProjA2, project-admin
- ProjH.ProjA.ProjA1.ProjectA3, project-admin
- ProjH.ProjA.ProjA1.ProjectA3, member
- ProjH.ProjA.ProjA1.ProjectA4, project-admin
̝
