Open Stack

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.

-- 
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1464750

Title:
  Service accounts can be used to login horizon

Status in OpenStack Dashboard (Horizon):
  Incomplete
Status in OpenStack Security Advisory:
  Won't Fix
Status in OpenStack Security Notes:
  In Progress

Bug description:
  This is not a bug and may / may not be a security issue ... but it
  appears that the service account created in keystone are of the same
  privileges level as any other admin accounts created through keystone
  and I don't like that.

  Would it be possible to implement something that would distinguish
  user accounts from service accounts?  Is there a way to isolate some
  service accounts from the remaining of the openstack APIs?

  One kick example on this is that any service accounts have admin
  privileges on all the other services .   At this point, I'm trying to
  figure out why are we creating a distinct service account for each
  service if nothing isolate them.

  IE:

  glance account can spawn a VM
  cinder account can delete an image
  heat account can delete a volume
  nova account can create an image

  
  All of these service accounts have access to the horizon dashboard.  One small hack could be to prevent those accounts from logging in Horizon.

  Thanks,

  Dave

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions