OSSG 25April2013 Minutes

[11:00:22] 	 #startmeeting OpenStack Security Group [11:00:24] 	 Meeting started Thu Apr 25 18:00:21 2013 UTC. The chair is bdpayne. Information about MeetBot at http://wiki.debian.org/MeetBot. [11:00:25] 	 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [11:00:27] 	 The meeting name has been set to 'openstack_security_group' [11:00:41] 	 jeblair is now known as jeblairtestnick [11:00:47] 	 good morning / afternoon / evening everyone [11:01:00] 	 hopefully everyone is recovered from the summit [11:01:05] 	 could we start with a role call? [11:01:26] 	 jeblairtestnick is now known as jeblair [11:02:40] 	 anyone here for the OSSG meeting? [11:02:54] 	 i'll chime in :-p [11:02:59] 	 hi! [11:03:03] 	 hi! [11:03:11] 	 hi! [11:03:20] 	 hi [11:03:22] 	 the message queue security stuff is interesting to me right now, maybe ewindisch has some ideas :) [11:03:34] 	 indeed, that's on the agenda for discussion today [11:03:39] 	 cool [11:03:52] 	 seems like multiple paths that could be taken [11:04:04] 	 be nice to agree on just 1 :-p [11:04:14] 	 ok, let's get started [11:04:26] 	 if nothing else, I'll have a nice log of myself typing [11:04:37] 	 #topic Summit Wrapup [11:05:01] 	 There were a lot of security related discussion at the summit this time around [11:05:06] 	 def [11:05:09] 	 Seems to be growing each time, which is great [11:05:10] 	 *which is great imho [11:05:12] 	 ya [11:05:15] 	 :-) [11:05:37] 	 now just to make some of it reality, thats the hard part, haha [11:05:40] 	 Themes I saw included key management / secret management, storage encryption, message queue / rpc security [11:05:54] 	 Also some interesting talks on using hadoop for log analysis [11:06:04] 	 And, of course, there was the NSA keynote [11:06:19] 	 any other topics from the summit worth calling attention to? [11:06:40] 	 hmmm, i remember one in nova about how to do live migration securely [11:06:56] 	 interesting… that's a tricky problem [11:07:04] 	 right now it requires shared keys, which is bad [11:07:04] 	 is that something being actively worked on for havana? [11:07:16] 	 unsure still [11:07:26] ChanServ sets mode +o openstack [11:07:44] 	 ok, that's something we can keep an eye out for [11:07:48] 	 def [11:07:52] 	 bdpayne: I suggested that rootwrap, for as long as it is used, should probably use linux system capabilities, rather than simply sudo to full root access. [11:08:04] 	 ahh yes, the root wrap discussion [11:08:08] 	 that's a good one too [11:08:15] 	 never ending root wrap discussion :-p [11:08:21] 	 linux capabilities does seem a useful possibility [11:08:22] 	 or at the very least, have the rootwrap process drop all privileges except execvp, so it can do things like logging, more safely [11:08:44] 	 I recall there being some concerns about non-linux systems, but that shouldn't be a show stopper [11:08:56] 	 we can put conditionals around the platform [11:08:57] 	 so, yeah, lots of things for security people to work on [11:09:15] 	 from an OSSG perspective, we got 8-ish new members to the group [11:09:15] 	 very much so [11:09:40] 	 would love to get more of the group engaged and think about how we can distribute the work of tracking and helping with all of these features [11:09:58] 	 given the light attendance today, I'll leave that as an action item [11:10:01] 	 :) [11:10:08] 	 ironic, perhaps [11:10:12] 	 radez_g0n3 is now known as radez [11:10:16] 	 ok, let's move forward [11:10:17] 	 likely everyone still trying to figure out what to do about havana, haha [11:10:26] 	 is the "secure live migration" issue described anywhere in more detail? [11:10:28] 	 bdpayne: we had to restart meetbot; you may want to "#startmeeting openstack security group" again [11:10:46] 	 ahh [11:10:49] 	 nicolae_: let me see if i can find anything, sorta remember which session it was in [11:10:58] 	 #startmeeting OpenStack Security Group [11:11:00] <@openstack>	 Meeting started Thu Apr 25 18:10:57 2013 UTC. The chair is bdpayne. Information about MeetBot at http://wiki.debian.org/MeetBot. [11:11:01] <@openstack>	 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. [11:11:02] openstack changed the topic to (Meeting topic: OpenStack Security Group) [11:11:03] <@openstack>	 The meeting name has been set to 'openstack_security_group' [11:11:28] 	 I'll need to check the conference sessions to find the live migration stuff [11:11:48] 	 live migrations depend on an ssh key [11:11:51] 	 may be an ether pad [11:12:09] 	 I know that I've spoken with Vish about this stuff a bit as well [11:12:12] 	 either every compute node has every other machine's public key, or they just share a private key. [11:12:20] 	 good times :-) [11:12:24] 	 ya, so the general problem is as ewindisch says [11:12:26] 	 oh, doesn't sound good :) [11:12:45] 	 so let's talk a little about the message security work [11:12:50] 	 #topic Message Queue Security [11:12:52] openstack changed the topic to Message Queue Security (Meeting topic: OpenStack Security Group) [11:12:59] 	 There's a very active email thread in -dev this morning [11:13:07] 	 http://lists.openstack.org/pipermail/openstack-dev/2013-April/007916.html [11:13:17] 	 this is a proposal from Red Hat [11:13:27] 	 there was also a proposal by erindisch at the summit [11:13:35] 	 arg.. that's ewindisch [11:14:05] 	 I do agree with the notion that we should probably, as a community, decide on a single good path [11:14:08] 	 any thoughts? [11:14:12] 	 http://lists.openstack.org/pipermail/openstack-dev/2013-April/thread.html#7916 also for the full thread [11:14:48] 	 cp16net is now known as cp16net|away [11:14:52] 	 bdpayne i'd like to reach a comprimse of sorts, since i believe there won't be a 1 ideal solution, but that doesn't mean we can't agree on something :-p [11:15:04] 	 ewindisch what is your take? I haven't had a chance to read the full thread [11:15:20] 	 The shared key solution is much more architecturally heavy, and the RedHat guys seem to gloss over that, imho. Basically, they suggest we take convenience over security, in some cases. [11:15:46] 	 and if we remove the convenience for more security, we get more architecturally heavy. [11:16:06] 	 that isn't necessarily a bad thing, but I feel they're a bit unwilling to admit it, at any rate. [11:16:20] 	 ok, fair point [11:16:34] 	 I feel like shared keys doesn't scale as well, which is basically what you're saying [11:16:40] 	 and cloud is really all about scale [11:16:53] 	 people are often scared of pki, but it has many benefits [11:17:59] 	 well, I would encourage people to chime in on the Red Hat thread [11:17:59] 	 a dev on our side had an interesting idea, about putting the control network in a vpn, securing that vpn, then leaving the rest of the stuff intact (and only opening the public url endpoints), but maybe thats different/not related [11:18:26] 	 harlowja: I honestly think that is a different concern altogether. [11:18:28] 	 that's not a bad idea, but it solves a different set of security problems [11:18:32] 	 yeah, that [11:18:35] 	 :-) [11:18:47] 	 ya, it sounded neat, haha [11:19:00] 	 also, ewindisch is your stuff available as a blueprint atm? [11:19:33] 	 bdpayne: very roughly. It doesn't have details. It should. [11:19:52] 	 given today's email thread, I wonder if it is time to flush it out [11:19:53] 	 I can take an AI to update the blueprint with a more concrete proposal [11:20:01] 	 and then have a discussion about pros and cons of each [11:20:07] 	 i'd like that, i trust ewindisch with security more than i trust myself ;) [11:20:21] 	 ewindisch I'm happy to help you out, if that's useful [11:20:23] 	 maybe nsavin u can help also [11:20:25] 	 just drop me a line [11:20:48] 	 bdpayne: I'd appreciate it. [11:20:55] 	 groovy [11:21:05] 	 ok, I have one more topic to discuss [11:21:25] 	 #topic OpenStack Security Configuration Guide [11:21:26] openstack changed the topic to OpenStack Security Configuration Guide (Meeting topic: OpenStack Security Group) [11:21:45] 	 so this is coming together but there are still some details to finalize [11:22:06] 	 cool [11:22:11] 	 keith would have the latest, but I can give some updates [11:22:42] 	 basically, we are still looking for June [11:22:56] 	 the facilitator we wanted has a conflict with the first week in June [11:23:12] 	 so we are looking for either a difference facilitator, or a different week [11:23:19] 	 so that's in flux a bit [11:23:28] 	 location appears to be out in Maryland [11:23:36] 	 participation is at around 10 people or so [11:23:47] 	 I'd love to got some more OpenStack specific people [11:24:06] 	 which is to say we have a lot of security folks with a medium amount of OpenStack experience [11:24:22] 	 I'd like to complement that with OpenStack people that have a medium amount of security experience (or more) [11:24:37] 	 hopefully we'll have 2-3 more people that can be involved [11:24:52] 	 bdpayne: are you seeking volunteers, recommendations? [11:24:53] 	 commitment would be a full week out in Maryland sometime in June (likely 1st or 3rd week) [11:24:59] 	 seeking volunteers atm [11:25:12] 	 sorry, I'm not selling it well enough [11:25:15] 	 :-) [11:25:31] 	 lol [11:25:34] 	 anyway, if you're interested, then drop me a line [11:25:40] 	 bdpayne: I'd have to check on time availability, but I'm interested. [11:25:44] 	 and I'll continue with more updates on this for future meetings [11:25:53] 	 ewindisch sounds good, I think you'd be an assest [11:25:59] 	 at any rate, I'm fairly local. [11:26:02] 	 or asset, as the case may be [11:26:05] 	 hmmm, i'll chat with y! people here [11:26:18] 	 sounds great, thanks harlowja [11:26:19] 	 can maybe volunteer one of them, haha [11:26:29] 	 #topic Open Discussion [11:26:31] openstack changed the topic to Open Discussion (Meeting topic: OpenStack Security Group) [11:26:34] 	 anything else for today? [11:26:42] 	 (we normally just run til 18030 [11:26:42] 	 mestery_ is now known as mestery [11:26:52] 	 live migration stuff, i can sumarrize what i remember [11:26:52] 	 *1830 [11:26:55] 	 ok [11:27:12] 	 i remember stuff like, can we have an intermediary give those keys out for only the duration of live migration (aka a orchestration layer) or can we eliminate the sharing of those keys entirely via some other mechanism (orchestration layer possibly establishing a secure tunnel for the live migration and telling the compute nodes to use said tunnel...).... [11:27:24] 	 Need to read the list and find your Information on the Security Document [11:27:31] 	 some kind of intermediary that connects the hypervisors for the duration of the live migration (And resize operation) [11:27:52] 	 i think it came up in https://etherpad.openstack.org/HavanaUnifyMigrateAndLiveMigrate but nothing documented there [11:28:29] 	 i can fire an email to the main dev thread, asking if we should at least document it somewhere [11:28:41] 	 ok, thanks for the details there… certainly worth collecting more info [11:29:08] 	 def, i know at least at y! we don't want hypervisors talking to each other, so live migration is sorta hard in that case :-p [11:29:38] 	 but an intermediary aiding that process might be acceptable [11:29:51] 	 *hand-holding the hypervisors in a way, haha [11:30:03] 	 interesting [11:30:08] 	 ok, I think that's all for today [11:30:16] 	 thanks everyone… nice to see some new faces in here [11:30:20] 	 #endmeeting [11:30:21] openstack changed the topic to OpenStack meetings || Development in #openstack-dev || Help in #openstack [11:30:23] <@openstack>	 Meeting ended Thu Apr 25 18:30:18 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4) [11:30:24] <@openstack> Minutes:       http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-04-25-18.10.html [11:30:25] <@openstack>	 Minutes (text): http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-04-25-18.10.txt [11:30:26] <@openstack> Log:           http://eavesdrop.openstack.org/meetings/openstack_security_group/2013/openstack_security_group.2013-04-25-18.10.log.html [11:31:11] 	 bdpayne: the reason for not wanting connectivity, is what happens if someone breaks out of a hypervisor, giving them those shared ssh keys would be bad :p [11:31:34] 	 its bad enough already due to the MQ itself and such [11:31:49] 	 likely someone could just jump on the MQ and start triggering live migrations right now, haha [11:31:57] 	 *not so awesome* [11:32:20] 	 oh, I completely agree! [11:32:47] 	 harlowja: I'm wondering if the host (losing the VM) can generate a short-lived key/token, send that to the host receiving the VM, then have that host use that key/token to pull off some mechanism. [11:33:19] 	 you'd need some transport mechanism that understands this and can be easily manipulated for the short-lived access control mechanism. [11:33:32] 	 (SSH is not a good solution here) [11:34:07] 	 "lots of MQ messages!"