Open Stack

On 4/28/15, 00:31, "Tripp, Travis S" <travis.tripp at hp.com> wrote:

>
>>On 4/27/15, 05:39, "Kuvaja, Erno" <kuvaja at hp.com> wrote:
>>
>>>The spec bluntly states that
>>>there is no security impact from the implementation
>>> and the concerns should have been brought up so reviewers would have
>>>had
>>>better chance to catch possible threats.
>>>
>>> 
>>>I would like you to look back into those two specs and the comments,
>>>look
>>>back into the implementation and raise any urgent concerns and please
>>>lets try to have good and healthy base for discussion in the Vancouver
>>>Summit how we will continue
>>> forward from this!
>>> 
>>>
>
>
>Any thoughts on improving security are always welcome.  As you¹ll find in
>the original service spec, in the comments on it, and in the code,
>security was one of the number one topics with the CIS service. Getting
>input on this was a driving reason to initially target a single OpenStack
>service (Glance). Security was also discussed in all three of the summit
>discussions leading to the creation of this service (pre-Kilo virtual
>summit, Kilo summit, Kilo mini-summit). Without security, this becomes an
>admin only service of limited interest and could be done completely
>outside of OpenStack as a native, possibly proprietary plugin to Elastic
>Search itself. In that scenario, it also would not have any input from the
>community and would not provide benefit to the broader community.
>
>https://review.openstack.org/#/c/138051/
>
>
>On 4/27/15, 10:52 AM, "Ian Cordasco" <ian.cordasco at RACKSPACE.COM> wrote:
>
>
>
>>
>>There¹s a slight problem with this though. We load the plugins
>>dynamically
>>https://github.com/openstack/glance/blob/582f8563e866f167ae1de1a2309c1a1e
>>2
>>4
>>84442a/glance/common/utils.py#L735 (as anyone really would expect us to)
>>which means new plugins can be created for any service that is willing to
>>create one and install it properly. With that done, we /could/ have CIS
>>become a centralized Elasticsearch API in OpenStack as managed by Glance.
>>
>>The solution that seems obvious for this is to disallow plugins to
>>declare
>>their index name (using PluginClass.get_index_name) but I don¹t think
>>that
>>warrants an RC3 or will necessarily make it into 2015.1.1.
>
>
>Thank you Ian for your continued thoughtful reviews. As Kamil pointed out,
>the index name also is a point of customization for deployers that might
>be using their elastic search cluster for multiple indexes.  If they want
>to change the index for any reason such as avoiding collisions, this
>allows that flexibility.

Sorry, so deployers are expected to do something like

class FixAssumptionsMadeByCIS(plugins.images.ImageIndex):
    def get_index_name(self):
        return ‘glance_made_an_assumption’

Why wouldn’t this be configurable in etc/glance-search.conf ? That seems
to me to be the best location for deployers to be configuring it. In fact,
isn’t that where everything that deployers are intended to configure is
supposed to go? In that case, I’m failing to see the reasoning for
`get_index_name`.

>
>>If CIS is going to become a fully supported (or non-experimental) Glance
>>API in Liberty, I think we should really make sure that it is a service
>>that can only create documents for Glance. Since the API is Experimental,
>>I think it¹s safe to say the API for the Plugins will be considered
>>experimental and so removing get_index_name from plugin classes will not
>>break the world.
>
>
>I have a summit session proposed on discussing the catalog index service
>at the summit and I specifically want to cover the scope and logistics of
>it moving forward. This includes discussing whether or not it should be
>proposed as its own project or if it might make sense for it to move to
>its own repo as part of the glance project for technical and logistical
>concerns. I¹ve started populating the linked discussion etherpad for that
>session proposal with a few thoughts. There appears to be another highly
>related session from Stuart, Flavio, and Brian that should be logically
>arranged so that the timing / coordination between the two sessions makes
>sense.

Cool. I’m looking forward to that session.

Cheers,
Ian