[Openstack-operators] [SOLVED] Glance Image Visibility Issue? - Non admin users can see private images from other tenants

Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.] michael.d.moore at nasa.gov
Fri Oct 26 18:38:22 UTC 2018


TL;DR: glance config doesn’t honor documented default setting for paste_deploy.flavor. Solution is to add setting to glance-api.conf. Patch to be submitted.

After the deep debugging yesterday Jonathan did a deep compare of our Mitaka configuration compared to Queens.

He noted that this section was missing in our Queens glance-api.conf (our config files are sparse and only specify values if the defaults are not correct for us)


[paste_deploy]
flavor = keystone

Adding that allowed Jonathan to set an image to public (publicize_image). It also made openstack image list (get_images) behave as expected

[root at vm013 common]# . /root/keystonerc_jonathan
[root at vm013 common]# openstack image list
+--------------------------------------+--------+--------+
| ID                                   | Name   | Status |
+--------------------------------------+--------+--------+
| 34a915b8-cca6-45c3-9348-5e15dace444f | cirros | active |
+--------------------------------------+--------+--------+


The Glance Queens configuration guide for glance_api states that the default paste_deploy.flavor setting is ‘keystone’

Refer to https://docs.openstack.org/glance/queens/configuration/glance_api.html

It’s readily apparent that without the setting in glance-api.conf that it does not behave properly which suggests it does not actually set keystone as the default

Glance common/config.py does not specify a default value for this setting, but it does specify a sample_default.

https://github.com/openstack/glance/blob/master/glance/common/config.py

lines 31-52

paste_deploy_opts = [


    cfg.StrOpt('flavor',


               sample_default='keystone',


               help=_("""


Deployment flavor to use in the server application pipeline.



Provide a string value representing the appropriate deployment


flavor used in the server application pipleline. This is typically


the partial name of a pipeline in the paste configuration file with


the service name removed.



For example, if your paste section name in the paste configuration


file is [pipeline:glance-api-keystone], set ``flavor`` to


``keystone``.



Possible values:


    * String value representing a partial pipeline name.



Related Options:


    * config_file



""")),


Modifying the code like so:

               sample_default='keystone',
               default=’keystone’,

               help=_("""



Makes it honor the documented default value.

I’ve submitted this as a patch on the bug report and a pull request on github.

https://github.com/openstack/glance/pull/9



Mike Moore, M.S.S.E.

Systems Engineer, Goddard Private Cloud
Michael.D.Moore at nasa.gov<mailto:Michael.D.Moore at nasa.gov>

Hydrogen fusion brightens my day.


From: "Moore, Michael Dane (GSFC-720.0)[BUSINESS INTEGRA, INC.]" <michael.d.moore at nasa.gov>
Date: Thursday, October 25, 2018 at 6:48 PM
To: Jonathan Mills <jonmills at gmail.com>, "iain.macdonnell at oracle.com" <iain.macdonnell at oracle.com>
Cc: "openstack-oper." <openstack-operators at lists.openstack.org>, "Thompson, John H. (GSFC-606.2)[InuTeq, LLC]" <john.h.thompson at nasa.gov>
Subject: Re: [Openstack-operators] Glance Image Visibility Issue? - Non admin users can see private images from other tenants


I have dug deep into the code for glance, shoving debug outputs to see what I can find in our queens environment.

Here is my debug code (I have a lot more but this is the salient part)

        LOG.debug("in enforce(), action='%s', policyvalues='%s'", action, context.to_policy_values())
        return super(Enforcer, self).enforce(action, target,
                                             context.to_policy_values(),
                                             do_raise=True,
                                             exc=exception.Forbidden,
                                             action=action)

below is the output attempting to set an image that I own while being an admin to public via `openstack image set –public cirros`

2018-10-25 18:29:16.575 17561 DEBUG glance.api.policy [req-e343bb10-8ec8-40df-8c0c-47d1b217ca0d - - - - -] in enforce(), action='publicize_image', policyvalues='{'service_roles': [], 'user_id': None, 'roles': [], 'user_domain_id': None, 'service_project_id': None, 'service_user_id': None, 'service_user_domain_id': None, 'service_project_domain_id': None, 'is_admin_project': True, 'user': None, 'project_id': None, 'tenant': None, 'project_domain_id': None}' enforce /usr/lib/python2.7/site-packages/glance/api/policy.py:64

And here is what shows up when I `openstack image list`  as our test user (`jonathan`) that is NOT an admin

2018-10-25 18:32:24.841 17564 DEBUG glance.api.policy [req-22abdcf2-14cd-4680-8deb-e48902a7ddef - - - - -] in enforce(), action='get_images', policyvalues='{'service_roles': [], 'user_id': None, 'roles': [], 'user_domain_id': None, 'service_project_id': None, 'service_user_id': None, 'service_user_domain_id': None, 'service_project_domain_id': None, 'is_admin_project': True, 'user': None, 'project_id': None, 'tenant': None, 'project_domain_id': None}' enforce /usr/lib/python2.7/site-packages/glance/api/policy.py:64


The takeaway that I have is that in the case of get_images, is_admin_project is True, which is WRONG for that test but since it’s a read-only operation it’s content to shortcircuit and return all those images.

In the case of publicize_image, the is_admin_project being True isn’t enough, and when it checks user (which is None) it says NOPE.


So somehow for some reason glance APIs context is super duper wrong.


Mike Moore, M.S.S.E.

Systems Engineer, Goddard Private Cloud
Michael.D.Moore at nasa.gov<mailto:Michael.D.Moore at nasa.gov>

Hydrogen fusion brightens my day.

 <snip chain to let message go to group>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20181026/30d22512/attachment.html>


More information about the OpenStack-operators mailing list