Open Stack

Hi,

I'm responsible for the spec for supporting CIS in the glanceclient, as well as the comments which brought some fuss, so would like to clarify some things.


1)      That's right - following scenario hasn't been included at the `Security Impact` section. That's because there is no real security impact here and I probably should rephrase the sentence to better match the current implementation status of the CIS. The user which is using the CIS API is not able to read/write any data from the cluster except from images and metadefs. He can't just ask for any resource type stored there and expect the results. Here is the quote from the spec comments:

"""Right now any access to resources stored outside of index name `glance` and document type `image` and `metadef` is forbidden by CIS. User is only allowed to play with documents which are registered within CIS."""

Additionally there is an RBAC implemented, but it has been well described in the original spec, so I won't repeat it here.

2)       """Would like to also address your concern that proposed shape of spec allows user to upload arbitrary documents to Elasticsearch (ES is the engine used under the hood, we should rather talk about uploading documents to CIS service) which are not related to Glance in any way (images & metadefs in current implementation).""" - The meaning of this sentence is (should be) not that storing arbitrary documents at CIS is not an issue of Glance. It says about uploading documents outside of the Glance mission (that's what I meant by "not related to Glance") which is prohibited by the CIS.

I would like to make it clear once more - the CIS doesn't allow the API consumer to operate on any data except Glance images and metadefinitions. CIS is not just exposing "raw" Elasticsearch capabilities, but it provides strict boundaries - using policy checks, RBAC and namespace protection (index/type in the Elasticsearch world) of what can be stored within it and what can be retrieved from it.

From: Kuvaja, Erno [mailto:kuvaja at hp.com]
Sent: Monday, April 27, 2015 12:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [glance] Call to action, revisit CIS state

Hi all,

As you probably know CIS was expanded from Juno metadefs work this cycle based on spec [1] provided. The implementation was merged in quite a rush just before feature freeze.

During the spec review [2] for client functionality for CIS it came to our attention that the implementation exposes Elasticsearch perhaps too openly via it's API (namely the creation of datasets allows API consumer uploading arbitrary files via the create request).

Call to action: Please review the CIS functionality again for security threats and bring them up so we can form a plan if we need to address those and request RC3 before release.

I have couple of major concerns about this workflow:

1)      I was shocked after reading following statement from the client spec review discussion: """During the Kilo release, we - by we I mean the team responsible for implementing the CIS - have discussed such scenario, that exposing Elasticsearch capabilities to the user consuming the CIS API can bring some serious security impact.""" This discussion nor the scenario was never brought to attention of the wider Glance community. 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.

2)      """Would like to also address your concern that proposed shape of spec allows user to upload arbitrary documents to Elasticsearch (ES is the engine used under the hood, we should rather talk about uploading documents to CIS service) which are not related to Glance in any way (images & metadefs in current implementation).""" """Personally I don't think that discussion about IF is a valid topic, because we've already implemented backend for CIS at the Glance side and you cannot say A without saying B.""" As long as the code is developed under the Glance project and reviewed by glance-core it's outrageous to claim that possible issues are not related to Glance in any way. Discussion about if the API is implemented by the spec and fits to the mission statement is really valid at this point and needs to be thoroughly discussed. We need to find the root cause of this attitude and fix it before it damages the relationships within the community in a way that cannot be fixed.

3)      We had two huge pieces of code merging in at the very end of the development cycle Artifacts and CIS and the pressure to merge them in (unfortunately not review but merge) was high. On the artifacts side we had pretty open discussion about the state, the concerns and plans of timelines address those concerns. With CIS we unfortunately did not have this openness. Was it reflection of 1 & 2 or something else, I do not know, but I surely would like to.

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! As Stable Branch Liaison I would really like to know what we (and who that we are) are supporting for next couple of cycles, as glance-core I would like to know any concerns about used technology or implementation people might have and as Glance community member I'd like to see us working together towards these things and definitely not have these "we" vs. "them"/"you" discussions anymore. Bluntly if we need to split the team, let's do it officially, there is room under big tent for every group who wants to be with themselves.

Best Regards,
Erno

[1] http://specs.openstack.org/openstack/glance-specs/specs/kilo/catalog-index-service.html
[2] https://review.openstack.org/#/c/173718/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150427/9edaa80b/attachment.html>