17:57:33 <SlickNik> #startmeeting trove
17:57:34 <openstack> Meeting started Wed Jan  7 17:57:33 2015 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:57:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:57:37 <openstack> The meeting name has been set to 'trove'
17:58:00 <SlickNik> Welcome back from the holidays!
17:58:15 <SlickNik> Giving folks a few minutes to trickle in
17:58:27 <SlickNik> Agenda is at: https://wiki.openstack.org/wiki/Meetings/TroveMeeting
17:58:39 <amrith> ./
17:58:54 <georgelorch> o/
17:59:10 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting
18:00:04 <peterstac> o/
18:00:07 <vgnbkr> o/
18:00:28 <vkmc> o/
18:00:39 <SlickNik> #topic Review: #131610 - Log operations - Need to address security concerns and a general review.
18:01:16 <sgotliv> o/
18:01:20 <amrith> #link https://review.openstack.org/#/c/131610
18:01:56 <SlickNik> X019 / iccha: want to give a quick overview?
18:02:10 <iccha> X019: the floor is yours
18:02:18 <dougshelley66> o/
18:02:38 <dloi> o/
18:02:47 <iccha> X019: around?
18:03:07 <amrith> she's on #openstack-trove
18:03:17 <sgotliv> guys, sorry for the stupid question - X019 is Anna?
18:03:22 <iccha> yes
18:03:24 <SlickNik> sgotliv: yes
18:03:36 <sgotliv> thanks
18:03:56 <iccha> i think she mainly wanted ppl to take a look at the updated spec
18:04:06 <iccha> and discuss any secuirty concerns folks may have
18:04:14 <iccha> esp sgotliv had brought up some points
18:04:34 <SlickNik> got it — was reading sgotliv's comments on the patch.
18:04:52 <iccha> and possibly brainstorm solutions if there were any suggestions
18:05:23 <sgotliv> my opinion is that user must be aware of this feature and be able to turn it off if needed
18:05:48 <amrith> sgotliv, who is the "user"
18:05:51 <SlickNik> sgotliv: Who is the user?
18:05:53 <iccha> sgotliv: would it be sufficient if we had a toggle enable_log_access ?
18:05:57 <amrith> the operator or the person getting the database instance?
18:06:02 <iccha> do u mean a deployer specific config?
18:06:28 <sgotliv> amrith, SlickNik we have 2 use cases public and private cloud, right?
18:06:34 <esmute> O/
18:06:41 <edmondk> o/
18:07:22 <amrith> sgotliv, yes
18:07:23 <iccha> the api calls auth a tenant, so a tenant cannot access another tenants logs anyways
18:07:59 <amrith> iccha, the issue sgotliv is raising is (i think) that the tenant should be able to prevent the admin user from getting logs off an instance
18:08:03 <amrith> if he or she desires.
18:08:10 <amrith> sgotliv, please confirm ^^
18:10:07 <amrith> have the intertubes got clogged again?
18:10:25 <dougshelley66> amrith, what you meant to say was "Is this thing on"
18:10:29 <SlickNik> amrith: what's preventing the admin user from ssh'ing into the box and getting the logs off in any case? I mean if the admin is suspect, there's are a lot of other vectors of compromise in which the admin user can get at the data.
18:10:50 <amrith> SlickNik, what's preventing that is the availability of an ssh key on the guest instance
18:11:47 <amrith> the guest image (in a private cloud, or public cloud which allows tenants to upload guest images) could be secured to the point where the admin can't get into it (in theory).
18:11:59 <SlickNik> but we don't guarantee that the key is not going to be on the image — since the admin user builds the image, he can just as easily bake a key into it.
18:12:11 <amrith> SlickNik, who's "we"?
18:12:23 <SlickNik> We = trove
18:12:25 <iccha> also though the user makes api call, it is also about who has access to the swift container as well
18:12:32 <iccha> the user could have constraints on that
18:12:55 <amrith> SlickNik, why should trove implement a feature with a level of security less than the rest of the system?
18:13:13 <iccha> amrith: do you have an alternate suggestion?
18:13:21 <SlickNik> amrith: Trove doesn't, and imo it should.
18:13:24 <amrith> currently, I could (as an admin) build a guest image that I can't login to (via ssh).
18:13:30 <SlickNik> shouldn't*
18:13:35 <amrith> SlickNik,  ;)
18:13:46 <SlickNik> Yes you can.
18:13:59 <SlickNik> That's my point.
18:14:12 <dougshelley66> point of clarification - is there a distinction between the operator/installer of the cloud components (such as trove) and the "admin" user?
18:14:15 <amrith> SlickNik, therefore a user could just as easily build such an image
18:14:28 <amrith> and then (without this feature), an administrator would be unable to get into it
18:14:34 <amrith> ssh or mysql or anything.
18:15:05 <SlickNik> What's the use case where a user builds a trove image to upload it into an untrusted cloud?
18:15:15 <amrith> it is a trusted cloud
18:15:26 <amrith> just that the trust doesn't extend to the administrators of the cloud
18:16:15 <amrith> SlickNik, you write, "I mean if the admin is suspect, there's are a lot of other vectors of compromise in which the admin user can get at the data". Each and every one of those would be security issues that should, I believe be fixed. No?
18:16:19 <amrith> if they exist
18:16:31 <amrith> I'm not sure what they are and this may not be the right forum to air them.
18:16:50 <amrith> sgotliv seems to have gone awol
18:17:04 <amrith> so I propose that we table this till he is back online
18:18:01 <amrith> I have an independent concern about this proposal and that is to do with swift integration. when manila comes along that would be the preferred place to put logs. How easy/hard would it be to make that change later?
18:18:01 <iccha> can we do it before the next meeting though? so anna X019 can start work?
18:18:25 <vipul> sounds like what is needed is real RBAC to our API, where there is a concept of an admin that's not necessarily the cloud administrator
18:18:31 <iccha> amrith: we should not worry about projects which are not integrated yet imo
18:18:40 <iccha> vipul: +1
18:18:59 <iccha> and at the same time we must be careful about feature creep
18:19:22 <SlickNik> It has to be trusted is my point. How does the user even know that the image he's uploaded is the same image that is being served by glance (and not one with a key inserted?)
18:19:36 <amrith> I'm not talking so much about RBAC as I am a switch which the tenant can flip. and the switch would prevent an admin from access to logs on this machine.
18:20:36 <amrith> SlickNik, at some level a tenant who issues the glance image-upload command gets an image id and uses that. of course, you could have a nefarious admin in the backend who substitutes one image for another.
18:20:50 <vipul> amrith: why would a tenant be able to deny an user with higher privileges?
18:20:56 <iccha> say if there is a real customer issue which needs the admins to go dig in, then?
18:21:23 <amrith> the question is whose admin.
18:21:27 <amrith> is it the cloud admin
18:21:32 <amrith> or an admin who the tenant authorizes
18:21:42 <amrith> anyway, I suggest we wait for sgotliv to return
18:21:45 <vipul> we only have two users today.. tenant and a cloud administrator
18:23:22 <SlickNik> IMO you wouldn't be able to guarantee data-privacy with any method switch or otherwise on the tenant side (and you probably wouldn't want to). A nefarious admin would always be able to get at the data.
18:23:24 <vipul> anyway.. if we have requirements where we need to enforce roles at a finer granularity besides the two we have today, i suggest adding policies
18:24:43 <vkmc> maybe if we carry a list of authorized users to perform that action?
18:24:53 * amcrn sneaks in a o/
18:25:01 <vkmc> something that only the admin user can modify
18:25:36 <SlickNik> Okay, let's continue this conversation on the review - IMO it's okay to have the API call and place a level of trust in the admin.
18:25:45 <iccha> +1
18:27:19 <SlickNik> Anything else on this topic?
18:27:21 <amrith> I would request that we allow sgotliv to chime in.
18:27:27 <amrith> he was here but seems to have dropped.
18:27:37 <amrith> not sure why/what happened there.
18:28:16 <SlickNik> amrith: Yup, that's why I suggested moving the conversation to the review — it'd give him a chance to chime in as well since he's not online.
18:28:21 <SlickNik> (at the moment)
18:29:14 <SlickNik> #topic Failures in https://review.openstack.org/#/c/141081/, we need a new guest image for int-tests to pass.
18:29:26 <amrith> SlickNik, this is mine. mostly a procedural thing
18:29:44 <amrith> there were a couple of comments about this review (141081) from you, peterstac and sgotliv
18:29:55 <amrith> the issue is that we don't have oslo.concurrency in the guest image
18:30:00 <amrith> there's a change submitted for that
18:30:23 <SlickNik> Yes, I saw that you submitted a chance to trove-integration for that.
18:30:28 <amrith> if we could get that merged once gate passes (almost done)
18:30:35 <amrith> then we'd be good (i think).
18:30:49 <peterstac> right - I'll remove the -1, due to the new submit
18:30:57 <amrith> peterstac, not so fast
18:31:03 <amrith> wait till the thing passes ;)
18:31:04 <SlickNik> #link https://review.openstack.org/#/c/145546
18:31:27 <amrith> gate is about 20 minutes from being done on that
18:31:39 <peterstac> ok, but it should just be a dependency then :)
18:31:56 <amrith> can't make it a dependency because one is in trove and one is in trove-integration
18:32:10 <peterstac> right
18:32:11 <SlickNik> yah just sounds like a cross project dependency (between the patch in trove, and the one in trove-int)
18:33:04 <SlickNik> Okay, sounds good. We can recheck the patch in trove once the trove-int dependency merges.
18:33:10 <SlickNik> And take it from there.
18:33:32 <amrith> that's all for that topic
18:33:35 <amrith> I think
18:33:39 <amrith> unless others have q's
18:34:06 <SlickNik> .
18:34:12 <SlickNik> Sounds good. Thanks!
18:34:19 <SlickNik> #topic Open Discussion
18:34:40 <amrith> got 1 ... mid-cycle. agenda, confirmations (headcount), ...
18:35:09 <peterstac> o/
18:36:27 <SlickNik> #action SlickNik to get an etherpad up for the mid-cycle agenda.
18:37:00 <SlickNik> Looks like most teams are brainstorming the agenda items on an etherpad.
18:37:13 <SlickNik> I have a few ideas I'll put down myself, and folks can add others.
18:38:01 <dougshelley66> SlickNik, how many people have registered?
18:38:49 <SlickNik> dougshelley66: I don't have a total count off the top of my head right at this moment — I can get it to you in the next hour or so.
18:39:03 <SlickNik> Still need to tally in some recent invites that came in.
18:39:06 <dougshelley66> SlickNik, thanks - just wondered
18:39:11 <amrith> o/
18:39:58 <SlickNik> peterstac: did you have a question?
18:40:06 <SlickNik> (amrith next)
18:40:22 <peterstac> no, just thought we were doing the headcount for the midcycle - sry@
18:40:33 <SlickNik> oh...
18:41:01 <peterstac> so Amrith's up ...
18:41:07 <SlickNik> peterstac: I was going to tally up the eventbrite RSVPs since folks might not be at the meeting.
18:41:11 <SlickNik> amrith: go for it
18:41:12 <peterstac> right
18:41:15 <amrith> SlickNik, did we tag 2014.2.2?
18:41:17 <amrith> slicknik, I saw this email http://markmail.org/message/xec3lpqlsipxum6h
18:41:17 <amrith> Looks like they reference Trove and give a link https://launchpad.net/trove/+milestone/2014.2.2
18:41:17 <amrith> which seems to be a dud.
18:42:36 <SlickNik> amrith: No the only changes between 2014.2.1 and 2014.2.2 were changes in requirements, so we didn't need a 2014.2.2 tag
18:42:56 <amrith> ok, thx
18:43:58 <SlickNik> that was as per my last conversation with ihar.
18:44:22 <SlickNik> I'm not sure if he sent that email out before or after our conversation.
18:45:01 <SlickNik> Okay — any other topics for open discussion?
18:46:30 <SlickNik> Looks like that's all we have for today.
18:46:32 <SlickNik> #endmeeting