17:00:20 #startmeeting Security 17:00:20 Meeting started Thu May 12 17:00:20 2016 UTC and is due to finish in 60 minutes. The chair is hyakuhei. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:24 The meeting name has been set to 'security' 17:00:29 o/ 17:00:29 o/ 17:00:30 o/ 17:00:36 hi * 17:00:39 hey hyakuhei :) 17:00:40 :D 17:00:50 long time no see! 17:01:42 #link https://etherpad.openstack.org/p/security-agenda 17:02:49 Looks like a quiet room this week - must be all this nice weather 17:02:55 I’ll go kick tmcpeak 17:03:29 :) he was just in a podcast with browne and me, so may be a sec 17:03:35 ooooh 17:03:38 Fancy! 17:03:45 seriously... 17:03:57 heh :) podcast.__init__ did an interview on Bandit 17:04:06 Sweet! 17:04:08 awesome! 17:04:25 should be live in about a month or so, so yeah watch this space i guess :P 17:04:31 lol 17:04:44 o/ 17:04:45 #chair elmiko 17:04:46 Current chairs: elmiko hyakuhei 17:04:49 #chair tkelsey 17:04:49 Current chairs: elmiko hyakuhei tkelsey 17:04:54 Anyone else want a chair? 17:05:04 I've got one, thanks! 17:05:16 sorry, that was bad 17:05:20 lol 17:05:20 It’s very sunny here and the wind is blowing out to sea… 17:05:29 I've got a standing desk, so I'm good on chair for now 17:05:32 #chair sicarie 17:05:32 Current chairs: elmiko hyakuhei sicarie tkelsey 17:05:34 sounds lovely hyakuhei 17:05:38 boo :) 17:05:42 Now you have two sicarie 17:05:45 LOL 17:05:47 redrobot: hipster. 17:05:52 o/ 17:06:14 ok lets run through the agenda then. For those of you late to the party: https://etherpad.openstack.org/p/security-agenda 17:06:16 I think I have finally updated my calendar to accurately reflect the real time of this meeting O:-) 17:06:28 ccneill: I normally do that just in time for DST to kick in 17:06:35 lol 17:06:37 #topic Anchor 17:06:48 yep, that's what messed with me :X 17:06:53 tkelsey: Anything much going on with Anchor from your end? Stan etc? 17:07:19 think its just you hyakuhei 17:07:28 ok cool, 17:07:30 humm, we found a bug in our "hello world" example around the standards verification filter ... but thats fixed now 17:07:36 rofl, yeah that was dumb 17:07:50 So today I was updating the (8 month out of date) Docker image 17:08:05 The problem with Anchor in Docker is that it exists with a pre-built key 17:08:08 oh yeah i forgot about hello world 17:08:27 Which means if you just run “docker run anchor” you’ll get a CA with the same private key that everyone else who’s run it is using. 17:08:31 Obviously dumb. 17:08:46 So although incomplete, today I got this working https://review.openstack.org/#/c/315675/1 17:08:55 WIP just for showing you guys atm 17:09:07 i see, interesting 17:09:26 So if you give it “-v /key” it’ll create a new key and new certificate 17:09:41 lgtm 17:09:55 if you create a key/certificate locally and give it ‘-v /key:mykeydir’ etc, it’ll use the key you’ve given it 17:10:00 Similar for config 17:10:06 sounds good to me 17:10:20 So the reason I bring this up is because I’m not really sure what best practice is for these things 17:10:30 This seems fairly flexible. 17:10:47 I think best practice would be to make a data container and put your key there 17:10:55 then mount the data container to the anchor container 17:10:57 well, that’s what -v does 17:10:58 i think doing a volume mount with the sensitive data is not too far out of alignment 17:11:10 At least, that’s what I thought it did 17:11:30 If you give it an empty volume called /key it’ll generate new stuff on the fly, if there’s stuff in the volume it’ll use that. 17:11:36 It doesn’t persist anything itself. 17:12:00 Very much open to improvements here, either on IRC or on the review - thanks elmiko redrobot 17:12:00 local volumen != data container 17:12:11 redrobot: true 17:12:40 According to some blog on the internet As of Docker 1.9.0, Docker has named volumes which replace data-only containers 17:13:09 heh bleeding edge FTW 17:13:11 interesting... there's always a pretty good chance that I have no idea what I'm talking aboug ;) 17:13:21 I’ll do more reading :) I’m fairly new to using docker for anything actually useful :) 17:13:51 Most of the time the volumes will be empty, which is just a nice way of doing things 17:14:04 TBH I’m thinking I should probably remove the pre-cut key altogether 17:14:14 that would be safest, imo 17:14:15 +1 sounds reasonable 17:14:24 since it should never be used 17:15:02 I need to ask around to see if anyone has a nice way of hooking dockerhub into OpenStack’s git so that containers get built whenever we make a change 17:15:11 tkelsey: That’s my thought yeah. 17:15:35 I might modify bootstrap so it always cuts a new key unless there’s a key in the /key volume then use that instead 17:15:51 where volume might actually need to be something else as per redrobot 17:15:53 one more point to consider on this topic, if you ever plan to build higher than docker, into kubernetes, there is also this option: http://kubernetes.io/docs/user-guide/secrets/ 17:16:04 Anyway, seemed somewhat useful so I thought I’d raise it 17:16:12 They’re like encrypted databags right ? 17:16:31 I was tempted to go down that road _or_ have anchor pull in data from env variables (which docker controls) 17:16:33 not sure about the encryption, but its a simple way to hold secrets for pods/containers 17:16:37 but volumes are _much_ easier. 17:16:55 I’ll make sure to take a look elmiko 17:17:01 That’s all I had on Anchor anyway. 17:17:15 #topic Bandit 17:17:36 so, padocast.__init__ just did an interview 17:17:46 *podcast.__init__ 17:18:01 seemed to go OK, should be live in a month 17:18:06 Sweet 17:18:19 A month!? Lots of editing then :P 17:18:22 browne tmcpeak and myself are in it 17:18:34 heh yeah, the chap has a pipeline of interviews to process 17:18:51 so awesome, grats to all =) 17:18:58 i'll post out the ML once I know more :) 17:19:11 woot! 17:19:15 Yeah that’s really great ! 17:19:18 thanks elmiko its nice that he reached out to us, means Bandit is getting more well known 17:19:29 thanks redrobot hyakuhei 17:19:57 not much else on the radar from me, any one else have anything? 17:20:20 ok cool. 17:20:33 Do we have any Syntribos peeps around? 17:20:42 howdy 17:20:44 :) 17:20:49 yup 17:20:55 mdong? 17:20:56 #topic Syntribos 17:21:04 Tell us all the things! 17:21:10 I think we've got most of us here. michaelxin might not be back at the office at the moment 17:21:13 sure 17:21:28 so we had a pretty long design session yesterday at the Castle to talk about our future direction 17:22:03 we're still working on improving existing tests for the time being 17:22:14 with a plan to test against mvaldes' vulnerable API within the next week or so 17:22:54 we have a deep dive meeting today to discuss our plans for improving a few existing tests (LDAP injection, buffer overflow, integer overflow, and SQLi) 17:23:01 rahulunair has also started the process of removing opencafe dependencies, starting with the client 17:23:06 yes ^ 17:23:30 we're actually looking for a good point-of-contact for planning our transition to more openstack-y things 17:23:43 e.g. oslo config/oslo logging/etc. 17:23:45 That’s very interesting! 17:23:55 nice! 17:24:15 I think we're gonna all go heads-down on it for a day or two to rip out all the remaining CAFE pieces, once we have a good idea of what we'll be replacing them with 17:24:38 hmm, what else.. 17:24:48 I think that's about it for the near-term 17:25:11 if anyone wants to volunteer to help us out with our CAFE transition (strategizing, not really writing code) 17:25:17 we'd really appreciate it O:-) 17:25:30 ccneill, I am interested in there 17:25:37 I don’t really know anything about CAFE :( 17:25:50 hyakuhei: what we really need is someone who's familiar with more openstacky things 17:25:59 oh, its this CADF? 17:25:59 elmiko: :D 17:26:03 i read it wrong 17:26:15 Heh, CADF != CAFE 17:26:25 I derped 17:26:28 I think we have a pretty good understanding of what pieces in CAFE we need to remove, and what they do for us 17:26:33 ccneill: what kinda of "openstacky things" would like you to know more about? 17:26:38 specifically, we’d like some help with oslo configs 17:26:47 i'd be happy to help 17:26:52 oslo config, oslo logging, potentially oslo messaging (I know so little about them I don't know whether we need this or not :X) 17:27:02 sweet 17:27:07 you da man, elmiko 17:27:10 i'm guessing you'l really want oslo.config and .logging 17:27:24 let's talk offline sometime 17:27:35 I'll reach out to you tomorrow if you have some time then? 17:27:39 sure 17:27:40 pretty packed with meetings today 17:27:44 just sent you my email too 17:27:45 sweet. thanks again 17:27:54 I think that's it for syntribos :) 17:28:45 Excellent! 17:28:52 #topic OSSN 17:29:02 Hmmm. To be honest I’ve not looked at these for a little while. 17:29:09 likewise 17:29:14 So put a rate-limiting ossn up for review 17:29:15 At the summit we spoke lots about turning these into Yaml or something 17:29:24 https://review.openstack.org/#/c/313896/ 17:29:42 TBH I think that’s doable with some up-front effort, just split the pile into 2-3 stacks and work on them, less than a days work to just manually change things. 17:29:48 Thanks lhinds 17:29:48 I was not sure if I needed to add reviewers myself, or core gets notified 17:30:14 didn't we run into technical issues with line length when nkinder looked at yaml before? 17:30:20 I also might have made a mistake and not branched first, but I compared the gerrit review page, and it looks ok 17:30:35 i.e. good to merge, if / when it passes review 17:31:14 I’ll take a quick look 17:31:23 What’s the #### Repose ### bit about? 17:31:23 The repose config in there was tested. I used the DoS script supplied in the launchpad bug, it worked well, or at least did the job. 17:31:35 Ah ok 17:32:05 That’s a very well researched OSSN lhinds :) 17:32:07 also I will still do a security group section as well, but wnated to not hold the OSSN back while I worked on it 17:32:10 Must have taken some work! 17:32:14 thanks hyakuhei 17:32:32 You get one security cookie! They’re rare! Don’t show the others though, they get jealous. 17:32:39 :) 17:33:12 haha, nice! 17:33:17 the other topic, was what you brought up - which is some sort of OSSN format that can be consumed downstream....e.g. SCAP content 17:33:20 #link https://bugs.launchpad.net/ossn - there’s a few in the queue now 17:33:23 Yeah 17:33:38 So SCAP want’s a _lot_ more than currently exists in OSSNs 17:33:46 but I’m happy to look at capturing that info 17:34:01 Problem is it’s hard because paths to $things are different per distro/deployetr 17:34:04 *deployer 17:34:15 hyakuhei, good point. 17:34:16 I’m 100% down for a computer readable format though. 17:34:26 That we can turn into other things 17:35:06 dave-mccowan: you around? 17:35:16 What’s the status on the Barbican/Nova/Key one? 17:35:20 maybe we can variable'ize root paths, which the dists then populate themselves 17:35:21 o/ 17:35:36 lhinds: potentially, I don’t really know how flexible SCAP is 17:35:37 $etc_keystone/keystone.cfg 17:35:39 hey dave-mccowan 17:35:50 What’s required for your OSSN ? 17:36:17 just reviews. i addressed all comments to date, but have not gotten any reviews on the latest patch. 17:36:33 oh ok, linky? 17:37:13 https://review.openstack.org/267800 17:37:39 I’ll try to review that before my 1900 meeting 17:37:48 Cool, anything else on OSSN? 17:38:17 ok, Travis is afk, anyone want to talk publicity? 17:38:31 If not we’ll move straight onto docs 17:38:36 #topic Docs 17:38:38 elmiko: sicarie 17:38:57 So we have a large review on the Manila chapter in-flight 17:39:08 Looks pretty good, but I haven't been able to review the last 3 files 17:39:39 Cool! 17:39:40 lhinds is hinting a rate-limiting section is coming, which will be awesome 17:39:51 I opened 2 bugs on general format stuff 17:39:53 lhinds is now our rate limiting guru 17:39:54 consistency 17:39:58 +1 :D 17:40:09 one of which has already been updated 17:40:16 hey no pressure eh ;-) 17:40:16 Sweet 17:40:25 lol 17:40:39 I need to re-ping the Neutron reviewers, but that's about it so far 17:40:52 +1 17:41:05 Sounds good, anything else? 17:41:19 Not from me 17:41:28 ok cool 17:41:32 #topic Blog 17:41:45 So I think one of my attempts to change the date on one of my posts broke things 17:41:51 =( 17:41:53 So you can push new posts but jekyll won’t update 17:42:02 go team! 17:42:08 I’ll fix it tomorrow AM hopefully. Unless someone else wants to? 17:42:21 I think you all have merge permissions 17:42:38 You do because you can also push straight to Master 17:43:01 Only blog in the queue is the reaction to the mis-information from the summit 17:43:43 hyakuhei: i have 2/3 blog posts in various states of "done-ness" 17:43:48 They're just not in my repo 17:43:49 cool! 17:44:00 I will have updates to the TA blog at some point, probably mid next week 17:44:00 * sicarie can't 'git' it 17:44:11 * elmiko groans 17:44:16 lol 17:44:25 sorry, my git-fu sucks, so it's the cleanest way for me 17:44:30 but I do have more coming 17:44:40 \o/ 17:44:58 lol 17:46:49 ok, lets roll on 17:46:55 #topic Threat Analysis 17:47:02 dg__: Anything? I’ve not looked this week 17:47:35 Guess not 17:47:40 #topic Any Other Business 17:48:06 hyakuhei no ive not touched it this week. RL. 17:48:13 Cool 17:48:13 catch up on TA next week? 17:48:16 Yeah 17:48:18 kk 17:48:31 So anyone got anything else to cover before we wrap up? 17:49:30 nothing from me 17:50:08 ok cool, thanks all! 17:50:14 o/ 17:50:17 #endmeeting