Jump to: navigation, search

Difference between revisions of "QuantumAuthZ"

 
Line 8: Line 8:
 
== Use Cases: ==
 
== Use Cases: ==
  
1) Allow only a “[[SuperAdmin]]”, typically [[QuantumManager]] in Nova to perform privileged operations such as plugging interfaces.
+
#1 Allow only a “[[SuperAdmin]]”, typically [[QuantumManager]] in Nova to perform privileged operations such as plugging interfaces.
2) Allow a [[TenantAdmin]] to create private network topologies and read network topologies.
+
#2 Allow a [[TenantAdmin]] to create private network topologies and read network topologies.
3) Allow a [[TenantUser]] to read the network topology relevant to the current tenant.
+
#3 Allow a [[TenantUser]] to read the network topology relevant to the current tenant.
4) Allow for ‘Global’ namespace that can be used for querying global service provider’s shared networks in a read-only mode. The goal is for service provider’s to have global shared networks such as “public-net” that is owned by the SP but can be discovered by any user with a valid keystone account and then the user can request his VM be connected to the Global shared network.
+
#4 Allow for ‘Global’ namespace that can be used for querying global service provider’s shared networks in a read-only mode. The goal is for service provider’s to have global shared networks such as “public-net” that is owned by the SP but can be discovered by any user with a valid keystone account and then the user can request his VM be connected to the Global shared network.
  
 
== Keystone configuration for Quantum: ==
 
== Keystone configuration for Quantum: ==
Line 29: Line 29:
 
=== Target “Quantum:Admin” workflow: ===
 
=== Target “Quantum:Admin” workflow: ===
  
1) Create a Keystone User
+
#1 Create a Keystone User
2) Grant global role “Quantum:Admin” to this user
+
#2 Grant global role “Quantum:Admin” to this user
3) Retrieve a token for this particular user
+
#3 Retrieve a token for this particular user
4) Allow [[QuantumManager]] in Nova or any other “Admin” resource to communicate with Quantum with this new keystone token.
+
#4 Allow [[QuantumManager]] in Nova or any other “Admin” resource to communicate with Quantum with this new keystone token.
  
 
=== Target “Quantum:[[TenantAdmin]]” workflow: ===
 
=== Target “Quantum:[[TenantAdmin]]” workflow: ===
  
1) Create a Keystone User
+
#1 Create a Keystone User
2) Grant tenant specific role “Quantum:[[TenantAdmin]]” to this user on a specific “tenant” as the scope of role.
+
#2 Grant tenant specific role “Quantum:[[TenantAdmin]]” to this user on a specific “tenant” as the scope of role.
3) Retrieve a token for this particular user
+
#3 Retrieve a token for this particular user
4) Allow Dashboard in Nova or any other “[[TenantAdmin]]” UI/CLI to communicate with Quantum with this new keystone token.
+
#4 Allow Dashboard in Nova or any other “[[TenantAdmin]]” UI/CLI to communicate with Quantum with this new keystone token.
  
 
=== Target “Quantum:[[TenantUser]]” workflow: ===
 
=== Target “Quantum:[[TenantUser]]” workflow: ===
  
1) Create a Keystone User
+
#1 Create a Keystone User
2) Grant tenant specific role “Quantum:[[TenantUser]]” to this user on a specific “tenant” as the scope of role.
+
#2 Grant tenant specific role “Quantum:[[TenantUser]]” to this user on a specific “tenant” as the scope of role.
3) Retrieve a token for this particular user
+
#3 Retrieve a token for this particular user
4) Allow Dashboard in Nova or any other “[[TenantAdmin]]” UI/CLI to communicate with Quantum with this new keystone token.
+
#4 Allow Dashboard in Nova or any other “[[TenantAdmin]]” UI/CLI to communicate with Quantum with this new keystone token.
  
 
== Implementation: ==
 
== Implementation: ==
Line 52: Line 52:
 
=== Standard Authorization implementation: ===
 
=== Standard Authorization implementation: ===
  
- Introduce an ‘authz’ middleware in the filter chain that a request must go through before hitting the Quantum Plugin.
+
* Introduce an ‘authz’ middleware in the filter chain that a request must go through before hitting the Quantum Plugin.
- ‘authz’ middleware will validate for privileged roles top-down  -> If ‘Quantum:Admin’ role is present, that role takes precedence, if not then we check if the token has ‘Quantum:[[TenantAdmin]]’ role on specific tenant that is under consideration, and finally check if the token has ‘Quantum:[[TenantUser]]’ role on specific tenant under consideration before rejecting the request with an HTTP 501: Unauthorized.
+
* ‘authz’ middleware will validate for privileged roles top-down  -> If ‘Quantum:Admin’ role is present, that role takes precedence, if not then we check if the token has ‘Quantum:[[TenantAdmin]]’ role on specific tenant that is under consideration, and finally check if the token has ‘Quantum:[[TenantUser]]’ role on specific tenant under consideration before rejecting the request with an HTTP 501: Unauthorized.
  
 
=== Global Shared read-only network authorization: ===
 
=== Global Shared read-only network authorization: ===
  
-     The Global shared read-only network use-case calls for an exception to the normal authorization workflow, where we have a user configurable tenant-id, let say ‘global’ that is configured in quantum.conf
+
* The Global shared read-only network use-case calls for an exception to the normal authorization workflow, where we have a user configurable tenant-id, let say ‘global’ that is configured in quantum.conf
- In case a user with none of the standard Quantum roles makes requests against the above ‘global’ tenant namespace, then only list_networks() operations is allowed and all other operations are disallowed.
+
* In case a user with none of the standard Quantum roles makes requests against the above ‘global’ tenant namespace, then only list_networks() operations is allowed and all other operations are disallowed.

Revision as of 18:00, 6 December 2011

Authorization in Quantum

Summary:

Authorization in Quantum will enable one to use Keystone tokens for authenticating as well as validating authorization over Quantum resources before performing Network (Quantum)-specific actions.

Use Cases:

#1	Allow only a “SuperAdmin”, typically QuantumManager in Nova to perform privileged operations such as plugging interfaces.
#2	Allow a TenantAdmin to create private network topologies and read network topologies.
#3	Allow a TenantUser to read the network topology relevant to the current tenant.
#4	Allow for ‘Global’ namespace that can be used for querying global service provider’s shared networks in a read-only mode. The goal is for service provider’s to have global shared networks such as “public-net” that is owned by the SP but can be discovered by any user with a valid keystone account and then the user can request his VM be connected to the Global shared network.

Keystone configuration for Quantum:

What are we not leveraging - Keystone’s Role-based Access Control (RBAC) that is targeted for Essex timeframe. The proposed RBAC features are currently not required for addressing Quantum use-cases and furthermore, RBAC in Keystone is not available for experimentation and integration testing.

What are we leveraging – We are leveraging the ability to create roles in Keystone and assign particular roles to specific users and tenants. We will add the following Quantum specific roles to the Keystone Server, where each of the roles provides certain specific capability

New Keystone roles for Quantum

Role “Quantum:Admin” – Quantum super user that can access any tenant and perform any action.

Role “Quantum:TenantAdmin” – Quantum Tenant Admin that can read tenant specific network topology and create private network topologies relevant to a particular tenant.

Role “Quantum:TenantUser” – Quantum Tenant User that has “read” access to all resources that are owned by the tenant.

Target “Quantum:Admin” workflow:

#1	Create a Keystone User
#2	Grant global role “Quantum:Admin” to this user
#3	Retrieve a token for this particular user
#4	Allow QuantumManager in Nova or any other “Admin” resource to communicate with Quantum with this new keystone token.

Target “Quantum:TenantAdmin” workflow:

#1	Create a Keystone User
#2	Grant tenant specific role “Quantum:TenantAdmin” to this user on a specific “tenant” as the scope of role.
#3	Retrieve a token for this particular user
#4	Allow Dashboard in Nova or any other “TenantAdmin” UI/CLI to communicate with Quantum with this new keystone token.

Target “Quantum:TenantUser” workflow:

#1	Create a Keystone User
#2	Grant tenant specific role “Quantum:TenantUser” to this user on a specific “tenant” as the scope of role.
#3	Retrieve a token for this particular user
#4	Allow Dashboard in Nova or any other “TenantAdmin” UI/CLI to communicate with Quantum with this new keystone token.

Implementation:

Standard Authorization implementation:

  • Introduce an ‘authz’ middleware in the filter chain that a request must go through before hitting the Quantum Plugin.
  • ‘authz’ middleware will validate for privileged roles top-down -> If ‘Quantum:Admin’ role is present, that role takes precedence, if not then we check if the token has ‘Quantum:TenantAdmin’ role on specific tenant that is under consideration, and finally check if the token has ‘Quantum:TenantUser’ role on specific tenant under consideration before rejecting the request with an HTTP 501: Unauthorized.

Global Shared read-only network authorization:

  • The Global shared read-only network use-case calls for an exception to the normal authorization workflow, where we have a user configurable tenant-id, let say ‘global’ that is configured in quantum.conf
  • In case a user with none of the standard Quantum roles makes requests against the above ‘global’ tenant namespace, then only list_networks() operations is allowed and all other operations are disallowed.