[openstack-dev] [glance] Call to action, revisit CIS state

Tripp, Travis S travis.tripp at hp.com
Tue Apr 28 05:31:29 UTC 2015




>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/582f8563e866f167ae1de1a2309c1a1e2
>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.


>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.




More information about the OpenStack-dev mailing list