Thanks for your response Kamil,

I think the first lesson learnt (again) is when there is >=1 non-native 
speakers involved make sure you understand the message as it's meant to, not as 
it has been written or you apprehend it. I'm happy I did not write what I had 
in my mind at Thu night or Fri morning but slept over the weekend as that 0 to 
v1 happened in no time.

All when revisiting the topic, please leave the edge off and lets ensure we 
have great Kilo release as intended. Still it's not too late to test the RC and 
make sure we don't have anything that needs panic fixing before final.


-          Erno

From: Rykowski, Kamil [mailto:kamil.rykow...@intel.com]
Sent: 27 April 2015 13:10
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Call to action, revisit CIS state

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:kuv...@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/

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to