Difference between revisions of "POC for QuotaManagement"

Revision as of 16:25, 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.

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.
• It is important to limit the maximum depth of the Project Hierarchy. Otherwise, the roles list can become huge.

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

Example 4

User B authenticates at "ProjH.ProjA", keystone will reject the authentication as User B does not have any role at "ProjH.ProjA". User B can authenticate using the scope as "ProjH.ProjA.ProjA1.ProjA3" or "ProjH.ProjB" or "ProjH.ProjB.ProjB2".

Quota Tables

There are four tables useful for Quota Management, namely "quotas", "quota_usages", "project_user_quotas" and "reservations" respectively.

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 at this level (User A has memeber and project-admin roles at this level). 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 at each level of the hierarchy starting from the scope level (as explained in the examples listed under Authentication Section). We can call this field as "rolesList". The "project_id" has the full hierarchy like "ProjH.ProjA.ProjA1.ProjA3"

"admin_or_project_admin":  "is_admin:True or  roleProjectAdmin:rolesList:%(project_id)"

This means that the user satisfies one of the following condition

• Cloud Admin
• function "roleProjectAdmin" will check that user has a project-admin role in the project_id using the the context field "rolesList"

The policy rules for the quota extension can be

"owner": "roleMember:rolesList:%(project_id)"   (means that user has any role except project-admin in the project)
"admin_or_project_admin_or_owner": "rule:admin_or_project_admin or rule:owner"
 
"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"

Concerns

• As nova keeps the complete project hierarchy in the Quotas table, 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 User removes the project "ProjA1" from the keystone, then nova should be notified about this.