18:00:30 <bdpayne_> #startmeeting OpenStack Security Group
18:00:30 <openstack> Meeting started Thu Mar 13 18:00:30 2014 UTC and is due to finish in 60 minutes.  The chair is bdpayne_. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:34 <openstack> The meeting name has been set to 'openstack_security_group'
18:00:45 <bdpayne_> hi everyone
18:00:46 <nkinder> hi all
18:00:49 <bknudson> hi
18:01:22 <malini1> hello!
18:01:49 <bdpayne_> #topic Roll Call
18:01:54 <bdpayne_> anyone else here today?
18:02:39 <bdpayne_> ok, I'm sure that others will trickle in
18:02:43 <bdpayne_> #topic Agenda
18:02:51 <hyakuhei> I'm here
18:02:57 <bdpayne_> So, I'd like to say a few words about the election
18:03:11 <bdpayne_> anything else people would like to discuss
18:03:12 <bdpayne_> ?
18:03:15 <hyakuhei> I vote that we all abstain, leaving Bryan as the only viable leader.
18:03:24 <nkinder> :)
18:03:37 <bknudson> Bryan probably won't abstain
18:03:55 <nkinder> I cna give an overall OSSN update
18:04:14 * bdpayne_ has already voted
18:04:25 <bdpayne_> ok, so election and OSSN
18:04:26 <bdpayne_> anything else?
18:05:20 <nkinder> there's been some interesting discussion around the keystone revocation vs. cache
18:05:37 <nkinder> might be worth some discussion to decide if it's OSSN worthy
18:05:44 <bknudson> the auth_token cache would be an interesting discussion
18:06:01 <bdpayne_> ok, sounds good
18:06:04 <bdpayne_> let's get rolling
18:06:05 <malini1> very interested in the keystone token stuff, do discuss
18:06:11 <bdpayne_> #topic Election
18:06:11 <coasterz> Hi all ;)
18:06:31 <bdpayne_> So I've been busy putting together everything for the election
18:06:46 <bdpayne_> bottom line is that, everyone in the electorate should have received an email with details on how to vote
18:06:56 <bdpayne_> if you believe you should be allowed to vote, and didn't get an email... let me know
18:07:11 <hyakuhei> I received an email a few minutes ago
18:07:13 <bknudson> got the email
18:07:16 <nkinder> me too
18:07:17 <bdpayne_> Also, I sent out an email yesterday with a link to a google doc
18:07:31 <bdpayne_> that showed who the active members where are how they received that designation
18:08:26 <malini1> me too
18:08:31 <bdpayne_> what I found was interesting actually was the IRC meeting participation
18:08:51 <bdpayne_> I wrote a script that shows how many meetings everyone participated in over the past year
18:09:03 <bdpayne_> in general, we have a core group of very active people
18:09:07 <bdpayne_> which is fantastic
18:09:20 <bdpayne_> anyway... bottom line is... GO VOTE :-)
18:09:25 <bdpayne_> any questions on the election?
18:09:52 <bknudson> thanks to those who stepped up!
18:09:52 <bdpayne_> if something comes up, just email me
18:10:02 <malini1> High Five to bdpayne and  hyakuhei for creating this active inclusive community
18:10:11 <bdpayne_> :-)
18:10:16 <bdpayne_> #topic OSSN
18:10:24 <bdpayne_> So what's the latest on the OSSN front?
18:10:47 <nkinder> We got a few published last week, which lowered the queue
18:10:51 <hyakuhei> I'm very excitied about the gerrit stuff
18:11:16 <nkinder> last I looked, we have 3 open issues and they are all assigned.  Someone new to OSSNs stepped up to take on the Cinder one.
18:11:29 <hyakuhei> there's one embargoed one too
18:11:42 <nkinder> hyakuhei: ok, is it being worked on?
18:12:26 <hyakuhei> Yes, though if someone has spare cycles for an OSSN we can bring them in
18:12:48 <nkinder> hyakuhei: ok.  Would you mind adding me to the issue?
18:12:49 <malini1> i have some spare cycles this coming week
18:13:08 <malini1> embargo -- this that a horizon one
18:13:19 <hyakuhei> I'll have to ok it with the owners but it should be ok.
18:13:24 <hyakuhei> malini1: nope, something else
18:13:50 <nkinder> For gerrit/git, it looks like I just need to ask infra to create the repo under the docs area.
18:14:24 <nkinder> That's on my list for this week, but Anne said that she's good with the plan to put it under docs.
18:14:35 <nkinder> We're also discussing how to go about getting OSSNs into the security guide
18:14:38 <hyakuhei> great, so who do you ask - Monty?
18:14:50 <bknudson> into the security guide or just published on the web page.
18:14:57 <nkinder> hyakuhei: I need to track down the right name...
18:15:01 <hyakuhei> nkinder: The idea was always to thread OSSNs into the guide
18:15:02 <bknudson> there's an #openstack-infra channel
18:15:10 <nkinder> bknudson: we're talking about how to feed them back into the guides
18:15:14 <hyakuhei> indeed, originally the idea was that the guide would be based on OSSNs
18:15:46 <nkinder> I think we may want to change the form of them, but get the info into the manual if it's a general "here's how you should deploy" sort of thing.
18:16:11 <bknudson> do we need a specific format? the Docbook XML or rst?
18:16:16 <nkinder> For issues that are addressed by new features or bug fixes, they would have a limited lifetime in the manual (whatever release is affected)
18:16:42 <nkinder> bknudson: I was going to ask annegentle about that when we get to it.
18:16:56 <hyakuhei> So I think at the moment 3-4 are referenced in the guide, they're just footnotes
18:17:00 <bknudson> are we going to "import" existing OSSNs?
18:17:22 <nkinder> bknudson: I think we should look at them.  There are only 8, so it shouldn't be bad
18:17:36 <hyakuhei> Sure - to my mind it's not a big problem to do, can be a quaterly task for the editors of the guide
18:17:41 <nkinder> I know the live migration one I published last week should definitely get into the guide in some form
18:17:50 <hyakuhei> Thread in a footnote and add the OSSN to an appendix perhaps?
18:18:09 <nkinder> hyakuhei: I think we want to go beyond that in some cases
18:18:27 <nkinder> hyakuhei: for live migration, I think the chapter on compute should talk about it in detail
18:18:42 <hyakuhei> Absolutely, I'm describing that as a minimum
18:18:47 <nkinder> hyakuhei: +1
18:19:02 <hyakuhei> The token-cache issue could be another potential one that deserves some inches in the guide.
18:19:18 <hyakuhei> ...depending on the fix
18:19:25 <nkinder> yes, one more thing before we switch topics to that
18:19:32 <malini1> hyakuhei: time to create a blog/article for Stefano M for his weekly communique on the history and goals of OSSN/OSSA/OSSG .. this catches a broad audience, often times getting picked up and re-transmitted at companies, and include the kind of data that bdpayne unearthed recently in compiling election list
18:19:47 <nkinder> for the git repo, I've been keeping my personal repo up to date - https://github.com/nkinder/openstack-security-notes
18:20:03 <nkinder> I'm planning on using this as a seed for the official repo
18:20:26 <nkinder> it has all published OSSNs and templates
18:20:37 <hyakuhei> Good idea.
18:20:43 <malini1> nkinder: NICE
18:20:50 <nkinder> ok, enough on OSSNs from me
18:21:06 <bdpayne_> hyakuhei can you continue running the meeting... I just got a phone call that I have to take
18:22:14 <bdpayne_> #topic Keystone Threat Assessment
18:22:24 <bdpayne_> I believe this was the other topic of discussion?
18:22:35 <nkinder> no, it was the keystone auth_token cache vs. revocation
18:22:59 <bdpayne_> oh, sorry
18:23:06 <nkinder> related though I guess
18:23:08 <bdpayne_> #topic Keystone auth_token cache vs revocation
18:23:16 * bdpayne_ is off the phone
18:23:19 <bdpayne_> sorry about that guys
18:23:27 <nkinder> So, this issue seems to be a balance issue to me
18:23:27 <bdpayne_> what's going on with the auth_cache stuff?
18:23:58 <nkinder> Much like PKI revocation checking, the deployer needs to think about what they are willing to live with
18:24:06 <hyakuhei> So if I recall correctly, this affects both 'traditional' and pki tokens.
18:24:15 <nkinder> I meant PKI in general
18:24:22 <nkinder> not as Keystone uses it
18:24:23 <bknudson> there's separate cache configuration for PKI vs UUID
18:24:42 <bknudson> the PKI path is to check the revoked tokens list
18:25:00 <bknudson> the revoked tokens list is cached. the default for cache timeout was 1 second... it's recently been updated to 300 sec
18:25:31 <bknudson> the UUID path is to check the cache, and if it's not in the cache then validate directly to keystone
18:25:40 <bknudson> so there's a cache for the UUID tokens.
18:26:00 <nkinder> this seems like the same sort of thing as deciding how often CRLs are generated vs. using OCSP with an X.509 setup... a deployment choice
18:26:12 <bknudson> well, ... actually, I think both UUID and PKI tokens use the cache at first.
18:26:17 <morganfainberg> nkinder, ++
18:26:32 <nkinder> so the default means that revocation won't be noticed for up to 5 minutes?
18:26:46 <hyakuhei> in the worst-case yes
18:26:48 <nkinder> ...and if you don't like it, you can make it smaller
18:26:53 <bknudson> #link https://wiki.openstack.org/wiki/Meetings/OpenStackSecurity
18:26:59 <bknudson> oops
18:27:05 <bknudson> #link https://bugs.launchpad.net/python-keystoneclient/+bug/1287301
18:27:28 <bknudson> so the defaults for both the caches are 300 seconds (5 mins)
18:27:37 <bknudson> so if your token was validated, it's good for 5 mins
18:27:41 <Shohel02> yes but there are there is no check for cached token
18:27:47 <morganfainberg> nkinder, perhaps the defaults are a bad assumption
18:27:49 <morganfainberg> nkinder, but it very clearly feels like a deployment choice
18:27:56 <bknudson> you can delete your token (invalidate it manually), and it'll still work for 5 mins
18:28:08 <bknudson> I guess part of the question is 5 mins a reasonable default.
18:28:17 <morganfainberg> bknudson, ++
18:28:27 <nkinder> everyone is going to have their own opinion on what is acceptable.  Is it 5 minutes, 30 seconds, immediate?
18:28:45 <hyakuhei> Deployment dependant. To answer it you need to have a good understanding of how, why, when and how frequently you'll want to kill a token
18:28:47 <morganfainberg> bknudson, i think 5 minutes is excessively aggressive, but iirc that is what we assume is the closest in-sync we can be due to clock skew?
18:28:53 <morganfainberg> erm, s/aggressive/lax
18:29:42 <hyakuhei> So, what are next steps here - one minute left on the meeting
18:30:16 <bknudson> I linked to the bug so if you have opinions you can bring them up there.
18:30:23 <nkinder> is the default stuck as is for Icehouse?  If so, we might want to mention in an OSSN
18:30:32 <bdpayne_> fwiw, I think that this sounds like a good use of an OSSN
18:30:39 <nkinder> deciding if a smaller default is needed is going to be a longer debate I think
18:30:40 <bdpayne_> and I would get too caught up in what the default is
18:30:44 <bdpayne_> 300 sec seems fine
18:30:52 <bdpayne_> people will need to tune it regardless
18:30:57 <bknudson> an OSSN makes sense to me.
18:30:58 <bdpayne_> at least that's my two cents
18:30:59 <hyakuhei> +1
18:31:21 <bdpayne_> ok, thanks everyone... nice meeting today
18:31:26 <hyakuhei> It's the tradeoffs thatneed to be documented, not the literal time
18:31:32 <bknudson> thanks
18:31:38 <bdpayne_> don't forget to vote :-)
18:31:48 <bdpayne_> #endmeeting