• QuantumAuthZ

Basic 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.

Note:

Authorization and Role Based Access Control (RBAC) can be pretty complex depending on the context of implementation and use-cases. This design doesn't intend to address all available RBAC use-case but rather attempts to get the ball rolling by delivering a simplistic AuthZ implementation that enables QuantumManager to do all Vif Plugging way while still enabling end-users ( tenants) to create custom network topologies. This is a start and as future Quantum releases happen, we will definitely try to include sophisticated capabilities being introduced in Keystone and enable fine-grained RBAC system.

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 401: 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.