18:01:21 #startmeeting OpenStack Security Group 18:01:22 Meeting started Thu Mar 14 18:01:21 2013 UTC. The chair is bdpayne. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:01:25 The meeting name has been set to 'openstack_security_group' 18:01:34 good morning everyone 18:01:48 hopefully the time change (in the US) didn't mess up anyone other than myself 18:01:58 could we get a quick role call? who is here? 18:02:17 here 18:02:27 I'm here 18:03:11 do we have estebang9 or noslzzp ? 18:03:51 ok 18:04:05 #topic Review action items 18:04:21 Last week I took on reviewing rbac 18:04:37 and looking at the idea of a doc sprint 18:04:59 Re RBAC… there's a lot to learn there 18:05:16 I've started down that path, but this is a actively evolving story in openstack today 18:06:00 bottom line, this is a work in progress 18:06:18 if anyone else is interested in this, I'd love to sync and share the load of planning how to do this 18:06:20 please let me know 18:06:26 Are there any wiki pages or emails on RBAC? 18:06:42 Not yet… I've just been trying to get my brain up to speed so far 18:07:12 But perhaps that would be a good step… to help gather information 18:07:34 any prefs on where to put something like that? 18:07:42 wiki, google doc, or ?? 18:08:12 What does the rest of the community use? It's probably best to use that to get more involved. 18:08:47 well, there is https://wiki.openstack.org/wiki/Main_Page 18:08:55 but I don't know that it's typically used in this context 18:09:40 I see people using https://etherpad.openstack.org/ sometimes for brainstorming-style notes and pages 18:09:41 The bad part about a wiki is how to edit it. I want to add comments, but not overwrite what someone else said. 18:09:49 I'd be inclined to use a google doc now for collar within our group, and then work on a more polished wiki when we are ready for broader input 18:10:41 I'm ok with that. 18:10:43 s/collab/collar/ 18:10:48 ok 18:10:59 #action bdpayne to collect rbac info into google doc 18:11:27 ahh, ether pad is reasonable as well 18:11:53 I could do it there too… probably a lower barrier to entry 18:12:08 so… moving forward 18:12:11 Re doc sprint 18:12:35 I have reached out to annegentle via email, but am still waiting for a response 18:13:07 I'm thinking it might be nice to do an effort like this in the May timeframe, leveraging momentum from the summit to get people involved 18:14:03 so, I guess just stay tuned for that 18:14:30 estebang9 was going to provide a recap of can sec, you here now? 18:15:13 alrighty 18:15:42 also, noslzzp was going to put up a PR for converting the hardening guide to markdown… and I haven't seen a PR for that yet 18:15:50 any updates there noslzzp ? 18:16:36 seems quiet today 18:16:46 yeah, I wonder if the time change is messing with people 18:16:47 that's ok 18:16:54 we can circle back on those items next week 18:17:18 #action bdpayne to check on markdown for hardening guide and can sec recap next week 18:17:35 ok, the last thing for today is Trusts, a new keystone concept 18:18:24 so ayoung asked me to discuss this today 18:18:38 basically he'd like some security input on this 18:19:09 let me see if it works to cut 'n paste his comments to me… 18:19:32 [10:54:40] token revocation in general is proving to be a source of many issues. 18:19:32 [10:55:01] One thing I'd like to emphasize moving forward is that with trusts, we should be able to move to short term tokens, and drop revocations 18:19:34 [10:55:17] I do like that 18:19:34 [10:55:20] You can see the bug I just filed 18:19:36 [10:55:43] in addition, there are issues about changing pretty much anything about a user, and then we revoke tokens. 18:19:36 [10:55:50] password, roles, domains, etc 18:19:38 [10:56:04] and gettting that right is proving troublesome 18:19:38 [10:56:33] so, instead, if something is going to take longer than just a web post and response, you should use a trust to follow up. 18:19:40 [10:56:42] An example is an upload event that takes minutes 18:19:40 [10:57:12] create a short term trust, hand it off to nova, and nova can then use that trust to get a token for swift in five minutes time 18:19:42 [10:57:21] So 2 things for the sec team 18:19:42 [10:57:38] 1. Make sure the trust implementation is solid 18:19:44 [10:57:51] 2. figure out where using trusts over long term tokens needs to happen 18:19:44 [10:58:19] and from those, we can move toward short term tokens and no revocation lists 18:19:46 [10:58:39] note that for tokens that have to be passed to Keystone, revocation is not an issue, as all things are checked on keystone at request time 18:19:46 [11:00:32] the issue there, if I think clearly through it, is that the unscoped token from Keystone is stored in the session, so we'd have to address that. 18:19:48 [11:01:03] I think we'd still keep the change password, revoke tokens logic. But that is the only one that carries roles. 18:19:56 there's a fair bit there, but I wanted to not mess up his words 18:20:10 he had a conflict and couldn't' attend today's meeting 18:21:07 * bdpayne gives everyone time to read through that 18:21:11 i can probably chime in if ya'll have questions 18:21:23 hi, thanks dolphm 18:22:08 so, I think that the main questions that come to my mind include (1) is this the right solution to the problem, and (2) is there a way that we can improve on the security here or do we like what is being done 18:22:30 for my mind, I'd need a fair bit more information to answer those questions 18:22:41 It's difficult to understand the problem and solution from these few lines. 18:22:47 dolphm, is there a good place for us to get some more background context and details on all of that? 18:23:08 bdpayne: i'm not aware of anything, no :( 18:23:19 that's unfortunate 18:23:27 we're basically solving for authz delegation and impersonation in one go 18:23:48 this is certainly a great area to get some solid security review 18:24:06 I think that to do that, though, we'll need to have a much more detailed discussion 18:24:15 "I trust user X to perform role Y on project Z, optionally for some duration of time, and optionally perform that role while impersonating me." 18:24:23 I'm open to conference calls, email threads, etc as appropriate 18:25:40 dolphm perhaps you could take this back and discuss with ayoung about a good next step to get security input? 18:26:58 ok, I'll take that one offline and see how we can move ahead 18:27:00 bdpayne: sure; but this is also shipping with grizzly :) 18:27:15 heh… so a little late for security review ;-) 18:27:28 but, perhaps still good to understand and improve all of this 18:27:47 any other topics for discussion? 18:27:54 i think it'd be great to have a flow chart to illustrate how trusts are defined, consumed, and utilized -- there's probably some impact there we haven't thought of 18:28:06 I have no doubt :-) 18:28:17 diagraming this out would be a good idea 18:29:06 ok, looks like we're done for today then 18:29:09 thanks everyone 18:29:12 have a great week 18:29:24 #endmeeting