Service accounts can be used to login horizon

[David Hill]

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

[Tristan Cacqueray (tristan-cacqueray)]

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

Should this need a Keystone task ?

[Tristan Cacqueray (tristan-cacqueray)]

Adding horizon and keystone coresec group to triage this bug report.

This is probably a class D type of bug ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy ).

[Adam Young (ayoung)]

This is a a dupe of Bug 968696

[Morgan Fainberg (mdrnstm)]

This is a case where some documentation could go a long way. The project/domain that the service users are located in should not have access to create new VMs (aka not have quota) etc.

In v2 we only have 2 real roles: admin and member. Validation of a token is an admin level call. This makes changing the base role for v2 difficult. I believe we could add a third role that is strictly a validate token role that service users get. However, I am unsure how that may impact service to service communication at this point.

In v3 it would be possible to provide a rich role set that is for the service users and doesn't include super-admin powers. Again he concern is what this will do for inter-service communication (nova -> neutron specifically).

The "hack to disable access to horizon" seems silly as it really adds zero security. If horizon wants to require a "dashboard" role to access it, it should be a separate task / not related to this bug.

This is (likely) an OSSN, and we need to evaluate what a change to the roles would end up entailing for service-to-service (would we break the world).

[Morgan Fainberg (mdrnstm)]

@adam,

It is slightly a duplication. It is a bit more specific.

@Tristan,

I agree, a class D

[Brant Knudson (blk-u)]

There are a couple of similar bugs:

 bug 1445199 - Nova user should not have admin role
 bug 1346778 - Neutron does not work by default without a keystone admin user

These are only documenting that the default configuration isn't what I'd like it to be. While I haven't gone through the exercise, I assume that through policy config you can set it up as you'd like. If you couldn't even set up your policy to be secure then that would be worse.

[David Lyle (david-lyle)]

Horizon allows users to login. Users are users. There is nothing in the user creation process that would flag a special case of user. Additionally, I could login as the same class of user from the CLI. x

Horizon will support the degree of RBAC as defined by operators or by the services (if the default is used) in policy.json files for the services. The bug is not a Horizon bug, but merely a view into the underlying issues Adam linked as the dup.

This is an OpenStack bug. Horizon is merely on window into the issue.

[Guang Yee (guang-yee)]

Yeah, I agree with the better documentation aspect. Using V3 APIs along with the policy.v3cloudsample.json policy file, token validation only need the "service" role.

https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L104

If you don't want an interactive service account at all, you may want to consider the X.509 tokenless authz feature once it landed.

https://review.openstack.org/#/c/156870/

With this patch, services can just use SSL client certs to talk to Keystone.

[Morgan Fainberg (mdrnstm)]

@Brant,

As long as v3 is used for validating tokens, we can use policy, but with v2 we can't even customize that.

Validating v3 should work for everything, but we aren't currently gating on this.

[Brant Knudson (blk-u)]

Service users like nova and neutron are used for more than just validating tokens. The nova service user is used to talk to neutron to provision networks, and the neutron user is used to notify nova that the network is available. Both of these are admin-only by default. There's probably other things that I don't know about. We made it way too easy to ignore security.

[Tristan Cacqueray (tristan-cacqueray)]

Thanks you for the quick debunk, adding ossg-coresec for an eventual OSSN task.

[Dolph Mathews (dolph)]

+1 to basically all the above analysis

[Tristan Cacqueray (tristan-cacqueray)]

This bug report seems to fall into the B2 category ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy ), thus I propose to remove the OSSA task and make it public next Monday, unless someone complains.

[Robert Clark (robert-clark)]

OSSN seems sensible, +1 with the above analysis.

[Travis McPeak (travis-mcpeak)]

OK - just to make sure I'm understanding the problem correctly (and can thus write a clear note) - this OSSN should document that:

in some configurations (all Keystone v2, some configurations of Keystone v3, Nova, Neutron) the service accounts are full cloud admin users. This means that they can perform all actions including logging in to Horizon.

Is this a fair assessment?

[Travis McPeak (travis-mcpeak)]

Also if ^ is correct- I'd rather just say "assume that service accounts have admin privileges and can do anything with your cloud".

[Kathleen Fischer (kathleen-fischer)]

This is something that definitely needs to be fixed. If Open Stack is to be approved for use by the Federal Gov't in any manner, all users and service accounts have to be able to abide by least privilege requirements and not be granted elevated privilege by default. A service account must be able to have access managed at the function of the service, not granted full cloud admin user rights. I am late into this conversation, hoping I am reading this wrong.

[Nathan Kinder (nkinder)]

@travis-mcpeak
With v3 of the Identity API, it's a matter of policy. In theory, roles and policies can be configured such that there is a 'services' role for token validation, and other special non-admin roles for operations such as the inter-service calls mentioned by @blk-u. I don't believe that anyone is actually defining their roles and policy in this way right now, but it is somethign that shoudl work and that we can recommend IMHO.

For v2 of the Identity API, all we can do in an OSSN is raise awareness that service accounts are equivalent to admin accounts.

[Dolph Mathews (dolph)]

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.

[Travis McPeak (travis-mcpeak)]

@ dolph, nkinder - got it, thank you for the summary. I'll start writing the note and loop Keystone folks in for the policy example guidance.

[Travis McPeak (travis-mcpeak)]

Throwing back the note task - this should really be taken up by somebody with more domain experience than I have.

[Adam Young (ayoung)]

A service user should have the "Service" role which can be used to validate a token, and little else. THis can be enforced with existing policy mechanisms.

[Adam Young (ayoung)]

It might make sense to have Horizon limit login to users with the Member or Admin roles only.

[Adam Heczko (aheczko-mirantis)]

Agree with Adam Y., although it's a pity that for example existing install guides are missing it and suggests to use "admin" role for services deployment.

[Nathan Kinder (nkinder)]

This has been published as OSSN-0055:

  https://wiki.openstack.org/wiki/OSSN/OSSN-0055

[Markus Zoeller (markus_z) (mzoeller)]

This bug report is specifically about the log into Horizon with a
nova service user. That the nova user has the admin rights is
covered in bug 1445199. That the admin role is not properly scoped is
handled in bug 968696. Nova cannot prevent/influence log ins to
Horizon. => Invalid for Nova

[Akihiro Motoki (amotoki)]

As Horizon, we can potentially check a role of log-in user. service users like nova and neutron usually belong to a specific role.

[Adam Young (ayoung)]

Would probably make sense to have a WebUser role that Member inherits. If a user has WebUser, they can log in to the ui, if they don't they can't. Horizon should not look for the absence of a role as a way to control UI.