Comment 19 for bug 1464750

Kathleen: That's already possible as a deployer option, but it's certainly not the default per the policy.json files we see across OpenStack today. You're correct in that the root problem here is one of overly broad authorization ("admin" should be broken down into many more roles with more specific use cases). It's a problem that exists across OpenStack. If anyone has gone through the effort of defining more granular roles for each service in OpenStack, they have not shared that work, much less upstreamed the resulting policy.json files.

Travis: The core issue here is not particularly relevant to keystone's v2 / v3 APIs, nor to Nova and Neutron. All services that I'm aware of use the concept of a "service" user which in most deployments receive overly broad "admin" level authorization (which should be clearly understood by everyone as being analogous to having "root" of the entire cloud). As I believe David Hill alluded in the bug description, those accounts generally have passwords just like regular users (and regular cloud operators) and can thus authenticate with keystone to generate tokens just as any other API user can. Given service user's "admin" authorization across OpenStack, they then have free reign to make any API calls they please. Whether or not Horizon is involved is entirely a non-issue, in my opinion.

As Adam pointed out, the problem described in bug 968696 is tightly related to this one, if it's not a duplicate. The only difference here is that service users are generally deployed with that level of authorization, when they should not, and ultimately do not, require it.