All operations are perfomed with admin priveleges when 'use_user_token' is False

[Mike Fedosin]

In glance-api.conf we have a param called 'use_user_token' which is enabled by default. It was introduced to allow for reauthentication when tokens expire and prevents requests from silently failing. https://review.openstack.org/#/c/29967/

Unfortunately disabling this parameter leads to security issues and allows a regular user to perform any operation with admin rights.

Steps to reproduce on devstack:
1. Change /etc/glance/glance-api.conf parameters and restart glance-api:
# Pass the user's token through for API requests to the registry.
# Default: True
use_user_token = False

# If 'use_user_token' is not in effect then admin credentials
# can be specified. Requests to the registry on behalf of
# the API will use these credentials.
# Admin user name
admin_user = glance
# Admin password
admin_password = nova
# Admin tenant name
admin_tenant_name = service
# Keystone endpoint
auth_url = http://127.0.0.1:5000/v2.0

(for v2 api it's required to enable registry service, too: data_api = glance.db.registry.api)

2. Create a private image with admin user:
source openrc admin admin
glance --os-image-api-version 1 image-create --name private --is-public False --disk-format qcow2 --container-format bare --file /etc/fstab
+------------------+--------------------------------------+
| Property | Value |
+------------------+--------------------------------------+
| checksum | e533283e6aac072533d1d091a7d2e413 |
| container_format | bare |
| created_at | 2015-09-01T22:17:25.000000 |
| deleted | False |
| deleted_at | None |
| disk_format | qcow2 |
| id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | private |
| owner | e1cec705e33b4dfaaece11b623f3c680 |
| protected | False |
| size | 616 |
| status | active |
| updated_at | 2015-09-01T22:17:27.000000 |
| virtual_size | None |
+------------------+--------------------------------------+

3. Check the image list with admin user:
glance --os-image-api-version 1 image-list
+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
| ID | Name | Disk Format | Container Format | Size | Status |
+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
| 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active |
| c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active |
| de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active |
| e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active |
+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+

4. Enable demo user and get the image list:
source openrc demo demo
glance --os-image-api-version 1 image-list
+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
| ID | Name | Disk Format | Container Format | Size | Status |
+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+
| 4a1703e7-72d1-4fce-8b5c-5bb1ef2a5047 | cirros-0.3.4-x86_64-uec | ami | ami | 25165824 | active |
| c513f951-e1b0-4acd-8980-ae932f073039 | cirros-0.3.4-x86_64-uec-kernel | aki | aki | 4979632 | active |
| de99e4b9-0491-4990-8b93-299377bf2c95 | cirros-0.3.4-x86_64-uec-ramdisk | ari | ari | 3740163 | active |
| e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 | private | qcow2 | bare | 616 | active |
+--------------------------------------+---------------------------------+-------------+------------------+----------+--------+

5. Try to get access to admin's private image with demo user:

glance --os-image-api-version 1 image-show private
+------------------+--------------------------------------+
| Property | Value |
+------------------+--------------------------------------+
| checksum | e533283e6aac072533d1d091a7d2e413 |
| container_format | bare |
| created_at | 2015-09-01T22:17:25.000000 |
| deleted | False |
| disk_format | qcow2 |
| id | e0d0bf2f-9f81-4500-ae50-7a1a0994e2f0 |
| is_public | False |
| min_disk | 0 |
| min_ram | 0 |
| name | private |
| owner | e1cec705e33b4dfaaece11b623f3c680 |
| protected | False |
| size | 616 |
| status | active |
| updated_at | 2015-09-01T22:17:27.000000 |
+------------------+--------------------------------------+

The same happens when demo user wants to create/update/delete any image. v2 with enabled registry backend is affected too.

[Jeremy Stanley (fungi)]

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.

[Mike Fedosin (mfedosin)]

Patch that removes all usages of use_user_token in Glance.

[Stuart McLaren (stuart-mclaren)]

Thanks Mike.

[Nikhil Komawar (nikhil-komawar)]

I don't like the fact that we are removing the config parameter all of sudden.

The issue is with deployments that have registry set in the pipeline and have exposed the Glance API to the users. This vulnerability does not affect those who use the Nova API as a pass-through Images API. (Please correct me if I am misinterpreting this).

Although, it does not explicitly state if bug affects v2 glance api, I assume from a comment in Step #1, it does.

Glance v1 API are mostly internal (non-public) APIs and I know for a fact that if you remove the config option, it will break some deployments and create big headache with Nova's interaction with Glance specifically during uploads. The https://review.openstack.org/#/c/29967/ has a real use case the proposal for removal of this option doesn't make sense.

We need to keep the default behavior to "True" and discuss potential deployment strategy (like advisory to not use use_user_token when API exposed to public users). Possibly involve stakeholders of the use case of this config parameter to consider alternate strategy for deploying internal glance api with same effect.

[Jeremy Stanley (fungi)]

We can broaden the audience by subscribing the ossg-coresec team for additional perspective, unless there are objections.

[Stuart McLaren (stuart-mclaren)]

Hi Nikhil

> This vulnerability does not affect those who use the Nova API as a pass-through Images API.

Good point -- we should check this out to be sure either way.

@Mike
Any chance you could test if 'nova image-list'/'nova image-show' shows this behaviour or not?

[Mike Fedosin (mfedosin)]

Hi, folks! I don't have devstack near, but I tested it on deployed Kilo. And yes - 'nova image-list'/'nova image-show' shows the same behaviour - all private images are available to any regular user: ('us' and 'them' are admin's private images)

root@node-1:~# source openrc_demo
root@node-1:~# glance image-list
+--------------------------------------+---------------------------------------------------+-------------+------------------+-----------+--------+
| ID | Name | Disk Format | Container Format | Size | Status |
+--------------------------------------+---------------------------------------------------+-------------+------------------+-----------+--------+
| d7d97046-b4af-4d56-abf8-9c1eb9d9d579 | cirros-0.3.2-x86_64 | qcow2 | bare | 13167616 | active |
| 70469139-274d-40a0-804c-62b49f5fbda6 | debian-8-docker.qcow2 | qcow2 | bare | 448724992 | active |
| 8283e3a4-aab5-4390-9c20-700ac9b0ed8a | debian-8-m-agent.qcow2 | qcow2 | bare | 464614400 | active |
| 973ad30c-cc5b-48c4-add3-7d926639ef96 | New Standard Image 1 | ami | ami | 42 | active |
| 18f02daa-8e43-489b-890b-2afff52dda8a | tempest.common.compute-instance-642617337-shelved | raw | bare | 41126400 | active |
| eae782fe-16d6-4012-8290-1854d02f2cb2 | TestVM | qcow2 | bare | 13287936 | active |
| 29cf8ea1-95fe-4438-9240-c4c148d458e6 | them | qcow2 | bare | 350 | active |
| 03d02f6e-f7fc-4ff7-8dab-8e774e6dff1a | ubuntu-14.04-m-agent.qcow2 | qcow2 | bare | 430693888 | active |
| 1bc5bb5d-c380-466f-9e67-495dd2fc7f48 | ubuntu14.04-x64-kubernetes | qcow2 | bare | 642580480 | active |
| 9795bda7-887f-413c-8ea8-5e1f957261b4 | us | qcow2 | bare | 350 | active |
+--------------------------------------+---------------------------------------------------+-------------+------------------+-----------+--------+
root@node-1:~# nova image-list
+--------------------------------------+----------------------------------------------------+--------+--------------------------------------+
| ID | Name | Status | Server |
+--------------------------------------+----------------------------------------------------+--------+--------------------------------------+
| 973ad30c-cc5b-48c4-add3-7d926639ef96 | New Standard Image 1 | ACTIVE | |
| eae782fe-16d6-4012-8290-1854d02f2cb2 | TestVM | ACTIVE | |
| d7d97046-b4af-4d56-abf8-9c1eb9d9d579 | cirros-0.3.2-x86_64 ...

[Mike Fedosin (mfedosin)]

Okay, I figured out another workaround, but I'm not sure how good it is.

The idea is to get 3 new headers to requests to registry server that will contain ID, roles and tenant of the real user. Then, on the registry side, create new context with these parameters and pass it to db api instead of admin's context.

Pros: we make 'use_user_token' work as expected and leave it in our config as a parameter.
Cons: v1 and v2 api impact; very bad workaround.

Alternative solution: deprecate 'use_user_token' for good. remove all the code from glance and relax.

Pros: very easy to implement, no api changes.
Cons: we remove some functionality in that case.

My wish to remove it all, because 'use_user_token' is kind of useless, it makes sense only in one case, when we want to change image status from 'saving' to 'active' when user token has been expired. In other cases I don't see any possibilities for it to help.
But I think it's better to write the new code that will handle the situation with token expiration, than keep this harmful param in our config.

[Nikhil Komawar (nikhil-komawar)]

Thanks Mike. Your finding makes me feel the same way.

However, I still think we need to consider the other use case. Once this parameter is removed it is likely that people who rely on it will have a significant number of snapshots failing and that to me sounds like a bad scenario. It's just one use case but is important. Also, the work on the token expiration won't land by the time this does.

@VMT team: Can we add Brian Rosmaita to this conversation? He can best repr the above use case and would be good to get his opinion on how bad the situation looks on their end.

[Jeremy Stanley (fungi)]

Please subscribe anyone you think may be able to help you come to a useful conclusion on this.

[Nikhil Komawar (nikhil-komawar)]

Thanks Jeremy, I have added Brian.

Brian, can you please give us an estimate of the impact?

[Brian Rosmaita (brian-rosmaita)]

Just want to acknowledge that I'm looking into this issue, I'll respond with something more concrete later.

[Stuart McLaren (stuart-mclaren)]

There was talk of using 'trusts' to prevent token timeouts. If trusts were implemented, it would be an alternative solution to the token timeout problem 'use_user_token' was trying to workaround.

[Mike Fedosin (mfedosin)]

Folks, let me summarize what we have:
1. Parameter 'use_user_token' does only one thing - switches user contex to admin's, that leads to the fact that all operations with registry server are performed with admin rights. It doesn't matter what api we do use: v1, v2 or even nova's. It happens here https://github.com/openstack/glance/blob/master/glance/registry/client/v1/api.py#L130, where the client replaces users data with admin credentials.

2. 'use_user_token' is really useless, because I can't imagine any use-case except of token expiration, where it may help users.

3. Nikhil said "Once this parameter is removed it is likely that people who rely on it will have a significant number of snapshots failing and that to me sounds like a bad scenario."
From my point of view it is bad scenario, too, but the security issue which can destroy your cloud is the worst issue and we have to make a choice.

4. About workaround with token expiration - I agree with Stuart, it's better to use trusts, but in Liberty we have passed FF and it's too big feature to implement it right in this small amount of time. In Mitaka it will be the highest priority for us (after artifacts, of course). But write the workaround is very easy - if we got auth error after successful file upload, then we do force status change with admin credentials, that's all.

5. Enabling 'send_identity_headers' param (https://github.com/openstack/glance/blob/master/glance/registry/client/v1/api.py#L34) doesn't help, because just admin credentials will be send instead of original user's.

6. Another solution I mentioned - to send additional headers with original user credentials and then handle them correctly on the server side, i.e. create new context object with right stuff. But yes - it's registry api change, and it's too dirty.

At least I want to see a warning in the configuration doc, like "if you disable this parameter your cloud will be fubar".

[Brian Rosmaita (brian-rosmaita)]

This is clearly a dangerous feature, but the default setting is use_user_token = True, and as far as we know, there are no security problems when use_user_token = True. I suggest that we add a warning to the doc along the lines of what Mike suggests above and then circulate a proposal on the ML that this option be removed in Mitaka.

There is a workaround if this feature is removed, namely to use the no-auth or trusted-auth pipelines, but these have their own peculiarities, so I'm kind of hesitant to just remove the setting in case there's a deployment using it in such a way that it works fine for that particular deployment and they don't want to use the alternative methods of connecting to the registry.

That being said, I don't believe that the intent of the use_user_token config option was to allow any user to have admin access to the registry. So as Mike points out, if we keep it around, it's going to have to be modified. But that might be pointless work unless people are actually using this option, so we can ask on the mailing list. I guess the problem with the ML suggestion is that once we ask about removing this dangerous option, anyone who's using it will be open to attacks, since more end-users will be aware that they can try to do actions they might not have tried before. But removing the option in L isn't going to help the people using it in pre-L, anyway.

[Jeremy Stanley (fungi)]

If you go the route of fixing in Mitaka and documenting for earlier releases, this is a primary case for an OpenStack Security Note (OSSN). It would be a good idea to subscribe the ossg-coresec group to this bug to evaluate that idea before we lift the embargo, so that we can at least have some coordinated notification accompanying the documentation updates.

[Nikhil Komawar (nikhil-komawar)]

Thanks Jeremy. I think that sounds like a good approach.

[Jeremy Stanley (fungi)]

I've subscribed the ossg-coresec team to this bug to solicit additional input.

[Mike Fedosin (mfedosin)]

Hi again! I wrote another, more relevant patch. It allows to keep 'use_user_token' as a parameter in config and not to change registry api at all.

The idea is to return the original meaning of this parameter - if it's disabled do not pass user's auth token in request to registry only. Because now in addition admin credentials are automatically set to the request. That's why I made new param in function 'get_registry_client' called 'use_admin_creds' , which explicitly tries to apply admin credentials to the request.

It's used only once in the code, when we want to change image status from 'saving' to 'active', as it's originally planned when 'use_user_token' was introduced https://bugs.launchpad.net/glance/+bug/1182536

Also I fixed several 500 errors, when NotAuthenticated exceptions were not handled.

And finally I made our functional tests to use user token, because they may be broken.
https://github.com/openstack/glance/blob/master/glance/tests/functional/__init__.py#L90

[Travis McPeak (travis-mcpeak)]

Sorry for the late response this one slipped through my inbox somehow.

I agree the feature seems dangerous. We can easily write a note to advise deployers not to set use_user_token to False but I can't see why anybody would want to do so anyway. Is admin the lowest privilege that would be able to change the status appropriately?

[Robert Clark (robert-clark)]

Hi All,

I don't know Glance well enough to comment on how/if the proposed mitigations might break things for downstream consumers

I agree that if this isn't going to be fixed until the next release then an OSSN would be appropriate over an OSSA though with issues of this severity I'm naturally inclined to favor a full Advisory.

Is there any way that an API user could probe to see if a deployment is vulnerable? Obviously they can't directly query the Glance API for the config parameter but is there anything they can attempt to do that as a side-effect would indicate whether a deployment has this issue - I'm assuming there must be?

[Robert Clark (robert-clark)]

If we do cut an OSSN for this, I think I'd like to do it under embargo, Travis and I are in the same timezone at the moment so can probably cut the OSSN pretty quickly if required.

[Mike Fedosin (mfedosin)]

Robert, Travis, thanks for your responses!

Another issue is we have this option disabled in our functional tests and it's not good at all: https://github.com/openstack/glance/blob/master/glance/tests/functional/__init__.py#L90 So I'm going to make a commit to fix it. Maybe today or tomorrow.

"Is there any way that an API user could probe to see if a deployment is vulnerable?" I think if a user can see, modify and delete all images in Glance, even if he's not the owner, then it means that deployment is vulnerable.

Let's do an OSSN then.

[Tristan Cacqueray (tristan-cacqueray)]

This looks like a B1 type of bug ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy ).
I've added an OSSN task and closed the OSSA task.

[Travis McPeak (travis-mcpeak)]

Great - I'll work with Rob on writing the security note ASAP.

[Nikhil Komawar (nikhil-komawar)]

I agree and glad that we have a OSSN for this.

Thanks all and especially Mike for all the work!

[Nikhil Komawar (nikhil-komawar)]

Since we are following on the agreement on OSSN ( from https://bugs.launchpad.net/glance/+bug/1493448/comments/22 ). I have moved the milestone to next for tracking in next rel.

[Brian Rosmaita (brian-rosmaita)]

I think I agree with everything, but let me summarize so I can be corrected:

(1) Security-side: An OSSN is going to be issued saying that using the non-default setting of use_user_token opens a deployment up to big security problems.

(2) Glance side: We'll either fix in Mitaka with something like Mike's patch or remove the use_user_token option altogether if no one appears to be using it.

This looks good to me.

[Nikhil Komawar (nikhil-komawar)]

2) Yes, we should set up a deprecation period for that config option starting the OSSN public declaration.

[Robert Clark (robert-clark)]

All,

I'd like, if possible, to follow something simlar to the OSSA process for this, we'll write up an OSSN, prep it and share it with you guys here. I think with an issue as severe as this we should probably share the OSSN with downstream stakeholders before making it public.

However, we are but humble servants, VMT owns this process so we'll do whatever they think is best, however I'd very much like this bug to stay private at least until the OSSN is ready (which we are already working on).

-Rob

[Travis McPeak (travis-mcpeak)]

Another open question is whether this should have an associated CVE... VMT- thoughts?

[Tristan Cacqueray (tristan-cacqueray)]

It's unclear if this really warrants a CVE since the flaw happen when the user sets "use_user_token=False" and adds admin credencials to the glance.conf.

In my opinion, the real issue is the lack of warning about the security consequence of this setting, and this doesn't warrant a CVE. This can be compared to a sshd configuration that enable root login without password.

[Brian Rosmaita (brian-rosmaita)]

Tristan, I've got a quick question based on your analogy. If some operating system vendor with a large install base printed sshd config instructions in a manual (or included the config commented out in a sample file or something) where the config was described to allow you to restart some service on a server, but it turned out that the config actually allowed root login without password ... would that merit a CVE? I think that situation is a bit closer to what's going on here. (Which isn't to say we need a CVE here, I'm just asking.)

[Jeremy Stanley (fungi)]

The OpenStack Vulnerability Management Team does not request CVE assignment on bugs for which it does not issue security advisories, e.g. those mitigated through corrections to documentation. That does not, however, preclude other interested parties (including the security notes editors) from requesting/issuing a CVE independently in those cases.

[Brian Rosmaita (brian-rosmaita)]

Jeremy, thanks for the clarification.

Travis and Robert, I don't have a lot of experience with this kind of thing, so I'll defer to you and others on the thread about whether it's worth pursuing a CVE.

I definitely agree with Robert's proposal to circulate the OSSN with downstream stakeholders before making it public.

[Travis McPeak (travis-mcpeak)]

IMO the only real advantage to having a CVE is to assign a unique identifier to the issue. We could probably get a similar thing by referring to the LP bug or the OSSN we are almost finished writing (OSSN-0060).

We'll post the OSSN contents here as a patch shortly.

[Robert Clark (robert-clark)]

Proposed OSSN

[Robert Clark (robert-clark)]

Replacement, accidentally uploaded the wrong one.

[Brian Rosmaita (brian-rosmaita)]

The OSSN looks good to me.

[Mike Fedosin (mfedosin)]

Yep, OSSN is good. Thanks Robert! I'm finishing the patch to fix our functional tests.

[Travis McPeak (travis-mcpeak)]

OK cool, since it seems folks are happy with the OSSN I'd like to see if we can get it distributed to stakeholders ahead of time.

VMT - Do you guys agree with this course of action? If so how should we go about it? I'm happy to do the work if you point me in the right direction.

[Robert Clark (robert-clark)]

Basically I think the ask here is that the OSSN be distributed to the VMT's pre-OSSA mailing list, and hold back opening this bug for whatever the normal time is for a pre-OSSA notification.

Unusual I know, but I don't want to be the operator who has this misconfigured and doesn't get a heads up first...

[Brian Rosmaita (brian-rosmaita)]

I entirely agree with Travis and Robert here.

[Mike Fedosin (mfedosin)]

Parameter 'use_user_token' in glance-api.conf
was considered as harmful and not acceptable
for real deployments, because if it's disabled
it changes system behaviour and allows any regular
user to perform requests with admin credentials.

This commit adds missing functional tests to v1 and
v2 APIs where it's shown how results of operations
are changed depending on this parameter. Also the
default value was set to True to prevent possible
failures in the future.

Besides, several admin authentication parameters were
deprecated as well, because they are useless without
'use_user_token'.

All required information was added to related
documentation sections, sample config file was updated,
too.

[Robert Clark (robert-clark)]

@jeremy + VMT peoples - thoughts on the process for releasing this info?

[Jeremy Stanley (fungi)]

Since Travis indicated an interest in sending a downstream pre-notification for this, I E-mailed him a current copy of our downstream stakeholders list on Friday.

[Travis McPeak (travis-mcpeak)]

Thanks Jeremy - I just got back from a long weekend but I'll be working on this today.

[Brian Rosmaita (brian-rosmaita)]

Travis, thanks for taking care of this. This offer is probably about 6 hours too late, but let me know if there's anything I can do to help.

[Travis McPeak (travis-mcpeak)]

Thanks Brian! I just sent out the note to the downstream stakeholders. We've indicated a general release date of October 14, so we'll open this bug and publish the OSSN then.

[Travis McPeak (travis-mcpeak)]

@VMT - it's been mentioned there are a large group of people in the "may be notified" section. Do we have any idea how they got here and given they've been added, is it reasonable to maintain embargo?

[Ian Cordasco (icordasc)]

Just a note. Some of us under "May be notified" are receiving email notifications about this and at least I can view this without being part of any of the groups added.

[Jeremy Stanley (fungi)]

It looks like the glance project has been configured to automatically share all private security bugs with the glance-bugs team. We should probably consider all private security glance bugs likely widely-known. I'll fix the sharing for glance in Launchpad in the meantime.

[Jeremy Stanley (fungi)]

Slight correction, it was the glance-drivers team not the glance-bugs team.

[Jeremy Stanley (fungi)]

Also, adding a task for OpenStack Security Notes has the effect of subscribing all members of the OpenStack Security (openstack-ossg) team due to the private bugs sharing configuration in place for it.

[Travis McPeak (travis-mcpeak)]

OK cool, thanks for looking into it Jeremy. In the future if we're considering a private bug we'll skip attaching the security notes project until it's ready for wider distribution.

[Jeremy Stanley (fungi)]

A simpler alternative is to remove the sharing for all OSSN private security bugs with the openstack-ossg team, since in these situations we'll subscribe the ossg-coresec team before hand anyway and they can in turn subscribe other individuals as needed.

[Travis McPeak (travis-mcpeak)]

Good point, that's the better solution. I'll remind Rob or Nathan to look into it.

[Robert Clark (robert-clark)]

@all. The emargo window has now closed. I think this can be opened up and we'll publish the OSSN

[Jeremy Stanley (fungi)]

I've switched this to a normal public bug with a security tag.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/237742

[David Comay (comay)]

Is there a schedule for this OSSN to be published?

[Robert Clark (robert-clark)]

Somehow it slipped through the net - the embargo'd one went out on time but the public one didn't.

It's just gone through review and is merging now:
https://review.openstack.org/#/c/272151

We've also published it on the wiki, as per our process. Travis should be sending the email out in the next few minutes.

[Nathan Kinder (nkinder)]

This has been published as OSSN-0060:

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/237742
Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=80fef06497c2a1f2e5c7bae4a0e04ab426ec70f7
Submitter: Jenkins
Branch: master

commit 80fef06497c2a1f2e5c7bae4a0e04ab426ec70f7
Author: Mike Fedosin <email address hidden>
Date: Fri Feb 12 19:43:13 2016 +0300

    Deprecate use_user_token parameter

    Parameter 'use_user_token' in glance-api.conf
    was considered as harmful and not acceptable
    for real deployments, because if it's disabled,
    it changes system behaviour and allows any regular
    user to perform requests with admin credentials.

    In functional tests the default value was set
    to True to prevent possible failures in the future.

    Besides, several admin authN parameters were
    deprecated as well, because they are useless without
    'use_user_token'.

    All required information was added to related
    documentation sections, sample config file was
    updated as well.

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

    Change-Id: Icfef49d787fa58e2af2e60e4fdc96633c5f0c010
    Related-bug: #1493448

[Mike Fedosin (mfedosin)]

"use_user_token" and related glance config options were deprecated in Mitaka: https://review.openstack.org/#/c/237742/

Bug may be closed.