Role Based Access Control (RBAC) as defined by NIST is based on the concept of global roles. Global, in this case, means the scope of the application. So if you have the role of ADMIN, and you are in a globally scoped RBAC based application, that role applies to all APIs and resources within the program.

OpenStack was written assuming that the ADMIN role was a global role. But then it was implemented as a non-global role. It was implemented as a role scoped to a tenant. The term tenant was the original (and I would argue, better) term for what was later called Project, and then again expanded to Domains as well.

A project, or a domain, or a tenant, or a namespace, is a way of sub-setting the resources in a system. Resources are explicitly labeled with exactly one name. When a user attempts to interact with that resource, the system checks the roles associated with the users account, and the rules will deny or allow the requested access.

However, the Nova project explicitly continued to use ADMIN in a global manner, and typically reserved it for sensitive operations. Keystone, on the other hand, assumed that ADMIN was a scoped role, and required that role to perform operations that were limited to a tenant. It is this disconnect that lead to the longevity of bug 968696.

So…is there any problem with continuing to keep ADMIN as a global role, even though it is assigned locally? Yes and no. The No comes from the fact that you can lock down all scoped operations to roles other than admin….OpenStack is going to use the term Manager instead. For example, a user with the manager role on a group will be able to add and remove people from that group. Thus, if you make it so no one actually needs the ADMIN role to perform day-to-day operations, and thus ADMIN is never required to be tied to a specific scope, you can make a functioning system.

TO continue the “NO” from above, you have to make sure that role assignments cannot lead to an elevation of principals. Thus, if the manager can assign roles to a user, they CANNOT be allowed to assign the ADMIN role to that user…unless they themselves have admin. Put more strictly, a user cannot be allowed to delegate any role that they themselves do not have. However, this means that a user needs to be explicitly assigned all roles that they can assign, or you need to be able to infer roles from the assigned roles. Keystone has role inference rules, and these are sufficient, if set up, to enforce this scheme. We have also hard-coded in a check that no role can imply the ADMIN role, essential to preventing elevation of privileges. It also performs inference cycle checks, so that a lower rule cannot point to a higher rule that points back to itself. Thus, if ADMIN directly or indirectly infers all other rules, you could never make a rule that then infers ADMIN.

With those two pre-conditions in place, you could make a system that allows ADMIN to continue to function globally even when assigned to a scope. However, those rules need to be enforced continually in the future. The problem would then come if some service creates or modifies an API that requires a scoped ADMIN to perform it. And, since RBAC enforcement is local to each server, this is not only possible, but likely based on history. If this happens, people will require a scoped ADMIN role, and in doing so, will get the unscoped power that comes with it. And, in the cases where there is automation and delegation involved (HEAT, Trusts, etc), there is going to be cases where these delegated credentials are stored on disk.

The current OpenStack approach is called Secure RBAC. That very term should raise alarms. RBAC by itself needs to be secure, and the need to put an additional qualifier on it indicates a problem. Changing all the APIs that required ADMIN to now require manager where Keystone treated it as a scoped role is opening up a huge security issue in all of the installations where ADMIN is assigned out. Perhaps this is not a real problem as the operators were already forced to limit it due to Nova. But there is a potential for abuse there. People that could not do role assignments on other domain and projects can do so now. As Keystone core, I would not have accepted this change.

Why does OpenStack insist on using ADMIN as a global role? Momentum. Inertia. It has always been done that way, and the users have built their workflow around the existing implementation. The previous attempt to replace project scoped roles with a different scoping mechanisms (System scoped roles) met with a thunderous NO from the Operators. That was after a quieter ‘no’ based on my own approached based on Admin-projects. They found admin projects confusing, and system scopes seemed more intuitive. I agree they were, but they ignored the inertia that the change needed to over come, and system scope comes with integration issues on its own.

I’ll write up why I think the admin-project approach is better in a follow on article. However, I think the current SRBAC effort to make ADMIN act as a global only role is a necessary step anyway. Distinguishing between global and privileges is an essential hardening scheme. Making more fine-grained roles that have limited scopes, and using them consistent across the OpenStack services is proper hardening. Locking down the role-assigment delegation rules in Keystone is essential. If all that is done, the addition of is_admin_project becomes and additional safety check, part of a defense in depth, and not the make-or-break it was when I originally wrote up the proposal.

The damage is already done. ADMIN is global, and proliferated. That is why most people do not expose their OpenStack APIs to their end users, and instead used things like CloudForms as a front to it. Or they wrote custom policy.