[openstack-dev] [keystone] Centralized policy rules and quotas

Florent Flament florent.flament-ext at cloudwatt.com
Thu Feb 6 10:22:20 UTC 2014


Spliting from thread "[openstack-dev][keystone][nova] Re: Hierarchicical Multitenancy Discussion"

Vinod, Vish:

I understand that actions are different from one service to the
other. What I meant is that the RBAC enforcement engine, doesn't need
to understand the "meaning" of an action. It can allow (or not) an
access, based on the action (a string - without understanding it), a
context (e.g. a dictionary, with data about the user, role, ...)  and
a set of rules.

>From the performance point of view, I agree that there may be an
issue. Centralizing RBAC enforcement would mean that every API call
has to be checked against a centralized controler, which could
generate a heavy load on it, especially for services that require a
heavy use of the APIs (like Swift for object storage). I believe that
the issue would be the same for quotas enforcement. Now that I'm
thinking about that, there's actually a similar issue with UUID tokens
that have to be checked against Keystone for each API call. And the
solution chosen to avoid Keystone to become a single point of failure
(SPOF) has been to implement the PKI tokens. They allow Openstack
services to work without checking Keystone every call.

I agree with Vish, that a good compromise may be to have RBAC/quotas
enforcement done in each specific service (altough by using a common
middleware, like for tokens validation?). At the same time, RBAC rules
and Quotas limits may be stored in a central place. There's already
some discussion that have been made (at least on the Quotas) some
months ago:
http://lists.openstack.org/pipermail/openstack-dev/2013-December/020799.html

I've got to catchup with what's been done on RBAC and Quotas, and see
if I can propose some improvements. If you have some interesting links
about blueprints / reviews about that I'd be interested.

+1 for the implementation of domain Quotas for Nova.

Florent Flament



More information about the OpenStack-dev mailing list