[RFE] Role-based Access Control for QoS policies

[Haim Daniel]

The cloud admin needs to have the ability to share Neutron QoS policies between subsets of tenants instead of the all-or-nothing choice he has now.

For example, there is no way for a cloud admin to define a "platinum" policy (e.g. guaranteed BW, low latency) and making it possible only for certain tenants (the ones who actually paid for it) applying it to their ports/networks.

In a similar context, a cloud administrator may want to apply a pre-created default policy (e.g. rate limit) for newly created networks/VM's .

This feature will add more more flexibility for network management workflows and provide the admin with support for real use cases encountered in enterprise/private-cloud deployments.

Suggested workflows for setting these permissions:

=================================
White listing for allowed tenants
=================================

-------------------------------------
Sharing a policy via the new RBAC API
-------------------------------------

# 1. admin creates qos-policy
* neutron qos-policy-create golden-policy [--description policy-description]

# 2. admin creates the rbac to allow only tenant-uuid1 of using it.
* neutron rbac-create golden-policy --type policy --target-tenant tenant-uuid1 --action access_as_shared

# 3. admin decides to share the qos policy with an additional (paying) tenant-uuid2
* neutron rbac-update golden-policy --target-tenant tenant-uuid2

From the perspective of a tenant2 that has a qos-policy shared to it, the policy will show up as 'shared' just like a globally shared policy would after aforementioned step 3.

------------------------------------
Stopping from a policy being shared
------------------------------------
* Note: deleting a qos policy rbac shall succeed as long as it's not bound to any ports/networks.

* neutron rbac-delete <rbac-from-step-3-uuid->

---------------------------
Globally sharing the policy
---------------------------
The new API preserves the legacy manner of globally sharing a qos-policy in either way:

# 1. Legacy API preserved: --shared switch
* neutron qos-policy-create --shared <policy-name>

# 2. New RBAC API way

* neutron qos-policy-create <policy-name>
* neutron rbac-create --type policy --action access_as_shared --target-tenant * <policy-name-or-uuid>

=======================
# Black listing tenants
=======================
As RBAC single allowed action is 'access_as_shared' at this time, there's no way of excluding tenants however, the sample flow is easy to come up with.

[Kyle Mestery (mestery)]

Seems very reasonable. I'd like Ihar and Miguel to have a peek here, adding them to the bug.

[Ihar Hrachyshka (ihar-hrachyshka)]

It was originally planned for Liberty but was postponed due to lack of time. See: https://github.com/openstack/neutron/blob/master/neutron/objects/qos/policy.py#L81

I totally agree QoS policies should be moved to RBAC.

[Kyle Mestery (mestery)]

Lets mark this confirmed then and let the work proceed.

[Miguel Angel Ajo (mangelajo)]

I discussed with Kevin Benton, about introducing a new type of action in RBAC for use with QoS (and potentially useful for other stuff),

The action would be default:

neutron rbac-create <qos-policy-id> --type qos-policy --target-tenant <tenant-uuid> --action default

That would mean:
   Any created network for that tenant would be assigned to the specific policy id by default.

May be "network_default" is a more appropriate name in such case. Adding Kevin to this RFE for comments.

[Miguel Angel Ajo (mangelajo)]

Probably my comment #4 should be matter of a separate RFE, and done once the initial RBAC is integrated. One step at a time.

[Haim Daniel (hdaniel)]

I agree with #4.

Just making sure - the correct flow from here onward is creating a neutron spec ?

[Miguel Angel Ajo (mangelajo)]

Within our policies It think no spec should be necessary: http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements

@ihar / @mestery, can you confirm?

[Armando Migliaccio (armando-migliaccio)]

Without the ability of sharing QoS policies, the cloud admin is left to creating the object many times as many times as the tenants who are in need of that policy. I think the spec is necessary as this involves quite a number of changes both client and server facing.

[Armando Migliaccio (armando-migliaccio)]

To be discussed at the drivers meeting.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/250081

[Miguel Angel Ajo (mangelajo)]

Ack @armax, let's talk about it next driver meeting. It was in the backlog of QoS, and that's why I understood we didn't need an RFE/Spec for it, but

It doesn't look like a big change to me though, but I believe we should keep the QoS emphasis on making use of this feature in a decoupled manner.

[Armando Migliaccio (armando-migliaccio)]

I'll let ajo chime in more, but I think a spec is needed based on discussion [1]

[1] http://eavesdrop.openstack.org/meetings/neutron_drivers/2015/neutron_drivers.2015-12-01-15.00.log.html

[Miguel Angel Ajo (mangelajo)]

Correct, let's proceed with the spec to clarify what we're doing (specially explaining that the API will stay put). Thanks @armax

[Miguel Angel Ajo (mangelajo)]

I think step 2 needs to be fixed to match the workflow with networks.

[--shared <rbac-uuid>] must be [--shared]. Also that's equivalent to not using --shared and
creating an RBAC entry to access_as_shared for "*".

[Armando Migliaccio (armando-migliaccio)]

Any status update here?

[Haim Daniel (hdaniel)]

Still an ongoing work - the patch has been through several review cycles.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/250081
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=aeaf77a5295080a3010a2e9c32e24f47c8cc73cc
Submitter: Jenkins
Branch: master

commit aeaf77a5295080a3010a2e9c32e24f47c8cc73cc
Author: Haim Daniel <email address hidden>
Date: Wed Nov 25 18:49:45 2015 -0500

    Qos policy RBAC DB setup and migration

    This patch implements a new database model required for the
    qos-policy RBAC support. In addition it migrates the current qos-policy
    'shared' attribute to leverage the new 'qospolicyrbacs' table.

    'shared' is no longer a property of the QosPolicy DB model. Its status
    is based on the tenant ID of the API caller. From an API perspective the
    logic remains the same - tenants will see qos-policies as 'shared=True'
    in case the qos-policy is shared with them). However, internal callers
    (e.g. plugins, drivers, services) must not check for the 'shared'
    attribute on qos-policy db objects any more.

    DocImpact
    APIImpact

    Blueprint: rbac-qos
    Related-bug: #1512587

    Change-Id: I1c59073daa181005a3e878bc2fe033a0709fbf31