Difference between revisions of "POC for QuotaManagement"
(→API URLs) |
(→POC Demo code) |
||
| (7 intermediate revisions by the same user not shown) | |||
| Line 11: | Line 11: | ||
== Authentication == | == 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 to the top i.e till the head node and construct the roles the user has at each level. See the following examples. | + | 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 to the top i.e till the head node and construct the roles set using the roles the user has at each level. See the following examples. |
===== Example 1 ===== | ===== Example 1 ===== | ||
| Line 44: | Line 44: | ||
===== Example 5 ===== | ===== Example 5 ===== | ||
| + | User C authenticates at "ProjH.ProjA.ProjA1.ProjA4", keystone will send the following information (or token) for this session.<br/> | ||
| + | <ins>Scope</ins><br/> | ||
| + | ProjH.ProjA.ProjA1.ProjA4 <br/> | ||
| + | <ins>Roles (find role at each project level upto the head node)</ins><br/> | ||
| + | * member | ||
| + | |||
| + | ===== Example 6 ===== | ||
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2". | User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2". | ||
| Line 72: | Line 79: | ||
When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user (User A has memeber and project-admin roles). As the user possess the "project-admin" role, the update operation on quotas is allowed. | When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user (User A has memeber and project-admin roles). As the user possess the "project-admin" role, the update operation on quotas is allowed. | ||
| − | The Keystone context will have a field which gives information about the roles in the hierarchy starting from the scope level and goes up to the head node(as explained in the examples listed under Authentication Section). We can call this field as " | + | The Keystone context will have a field which gives information about the roles in the hierarchy starting from the scope level and goes up to the head node(as explained in the examples listed under Authentication Section). We can call this field as "roles". The "project_id" in the keystone context has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3" |
| − | + | "context_is_admin": "role:admin" | |
| + | "project_admin": "role:project-admin and project_id:%(project_id)s" | ||
| + | "admin_or_project_admin": "rule: context_is_admin or rule:project_admin" | ||
This means that the user satisfies one of the following condition <br/> | This means that the user satisfies one of the following condition <br/> | ||
*Cloud Admin | *Cloud Admin | ||
| − | * | + | *check that user has a project-admin role using the the context field "roles" and has the selected project_id scope |
The policy rules for the quota extension can be | The policy rules for the quota extension can be | ||
| − | " | + | "member": "role:member and project_id:%(project_id)s" (means that user has role member in the project) |
| − | " | + | "admin_or_project_admin_or_member": "rule:admin_or_project_admin or rule:member" |
"compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner", | "compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner", | ||
| Line 91: | Line 100: | ||
== POC Demo code == | == POC Demo code == | ||
Please check the code snippets for this setup at <br/> | Please check the code snippets for this setup at <br/> | ||
| − | https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/ | + | https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/4147173a415108e9496d6265522ea57bec5d1409 |
== Concerns == | == Concerns == | ||
| − | * | + | * The project_id in the Nova Quota tables should include the complete hierarchy. Because of this, it is necessary to notify Nova about any changes in the hierarchy. For example, Nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and if Admin removes or shifts (to another parent node) the project "ProjA1" from the keystone, then Nova should be notified about this. |
Latest revision as of 16:32, 6 April 2014
Contents
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.
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 to the top i.e till the head node and construct the roles set using 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 head node)
- admin
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 head node)
- 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 head node)
- project-admin, member
Example 4
User A authenticates at "ProjH.ProjA.ProjA1.ProjA3", keystone will send the following information (or token) for this session.
Scope
ProjH.ProjA.ProjA1.ProjA3
Roles (find role at each project level upto the head node)
- project-admin, member
̽Noteː
- It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the paring may take a very long time.
Example 5
User C authenticates at "ProjH.ProjA.ProjA1.ProjA4", keystone will send the following information (or token) for this session.
Scope
ProjH.ProjA.ProjA1.ProjA4
Roles (find role at each project level upto the head node)
- member
Example 6
User B tries to authenticates at "ProjH.ProjA" but keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". That means User B is not part of Project "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB.ProjB2".
Quota Tables
There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.
| Table | Description | Important Fields |
|---|---|---|
| quotas | Stores the quota values for resources (like instances, cores etc) of a Project | project_id |
| project_user_quotas | Stores the quota allotment to a User in a Project | project_id, user_id |
| quota_usages | Stores the quota already in use by a User in a Project | project_id, user_id |
| reservations | Stores the reservations made for a resource by a User in a Project | project_id, user_id |
The project_id field in these tables stores the project complete hierarchy, like if quota values are defined for "ProjA1", then the project_id is "ProjH.ProjA.ProjA1".
API URLs
The URLs does not need to include any project names up to the authentication scope. The URLs only need to include the hierarchy after the scope for executing an operation. For example, if User A authenticates using scope as "ProjH.ProjA" and the User A want to update the quotas assigned to "ProjH.ProjA.ProjA1.ProjA3", then the URL can be like
PUT Request -> http://<nova listening ip>:8774/v3/os-quota-sets?project_id=ProjA1.ProjA3
When the above URL fired, the complete hierarchy will be formed by prepend the scope id to the project_id in the URL, that means here it will be "ProjH.ProjA.ProjA1.ProjA3". Now, the program can check the role possessed by the user (User A has memeber and project-admin roles). As the user possess the "project-admin" role, the update operation on quotas is allowed.
The Keystone context will have a field which gives information about the roles in the hierarchy starting from the scope level and goes up to the head node(as explained in the examples listed under Authentication Section). We can call this field as "roles". The "project_id" in the keystone context has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"
"context_is_admin": "role:admin" "project_admin": "role:project-admin and project_id:%(project_id)s" "admin_or_project_admin": "rule: context_is_admin or rule:project_admin"
This means that the user satisfies one of the following condition
- Cloud Admin
- check that user has a project-admin role using the the context field "roles" and has the selected project_id scope
The policy rules for the quota extension can be
"member": "role:member and project_id:%(project_id)s" (means that user has role member in the project) "admin_or_project_admin_or_member": "rule:admin_or_project_admin or rule:member" "compute_extension:quotas:show": "rule:admin_or_project_admin_or_owner", "compute_extension:quotas:update": "rule:admin_or_project_admin", "compute_extension:quotas:delete": "rule:admin_or_project_admin"
POC Demo code
Please check the code snippets for this setup at
https://github.com/vinodkumarboppanna/POC-For-Quotas/commit/4147173a415108e9496d6265522ea57bec5d1409
Concerns
- The project_id in the Nova Quota tables should include the complete hierarchy. Because of this, it is necessary to notify Nova about any changes in the hierarchy. For example, Nova stores Quotas of Project "ProjH.ProjA.ProjA1" in the table and if Admin removes or shifts (to another parent node) the project "ProjA1" from the keystone, then Nova should be notified about this.
