RBAC -access_as_external - exclude tenant

[Alex Stafeyev]

If we have 50 tenants and we will want to expose the external network to 49 of them, we will have to create 49 rbac rules.
IMHO it can be not so comfortable.

I believe we should make an option to exclude specific tenant/tenants from being targeted by the rbac rule.

May be we can add attribute "exclude_tenants" to the RBAC policy in order to make it happen.

MITAKA

[Kevin Benton (kevinbenton)]

This is a feature request. Currently the RBAC mechanism is a whitelist so adding blacklist capabilities will take quite a bit of work.

[Ihar Hrachyshka (ihar-hrachyshka)]

While it's nice to have exclusion mechanism, is it really worth it complicating the code for that? What's the problem with having multiple RBAC entries? Does it significantly slow down any API operations?

Or it's just a matter of involving orchestration to maintain all those RBACs as a single logical policy? Even with the proposal implemented, you would still need to maintain multiple RBACs entries for your needs (one global + one exclusion).

[Alex Stafeyev (astafeye)]

We think it is very not comfortable from a users side.
It is ok to have multiple policies but it is less nice to do all that work for such a small change ( remove one tenant from the exposed tenants list).

Do we need to make it more comfortable? IMHO yes.
Is it worth the effort, or, complicating the code for that? This is not for me to decide :)

BR

[Carl Baldwin (carl-baldwin)]

Update from Drivers' meeting: http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-06-02-22.00.log.html#l-124

[bjolo (bjorn-lofdahl)]

how would heat and tmp projects work in this context? does it follow the rbac rules based on the "parent" project? If we must whitelist each and single project to have access to a network, heat will fail right?

Im in favor of having some form of blacklisting/deny capabilities

bjolo