17:00:55 #startmeeting security 17:00:56 Meeting started Thu Aug 31 17:00:55 2017 UTC and is due to finish in 60 minutes. The chair is lhinds. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:00 The meeting name has been set to 'security' 17:01:09 o/ 17:01:17 hi dave-mcc_ ! 17:01:18 o/ 17:01:26 oh and browne , cool! 17:01:50 hyakuhei mdong around? 17:01:54 o/ 17:02:01 hey mdong 17:02:14 #topic agenda: 17:02:17 https://etherpad.openstack.org/p/security-agenda 17:02:31 anyone wish to make additions, please do.. 17:02:45 I will get the ball rolling in the meantime. 17:02:48 o/ 17:02:55 #topic electing more cores. 17:02:58 hey gagehugo ! 17:03:42 so I wanted to seed an intial discussion around what we could do to encourage some cores..mainly starting with syntribios and bandit ( mdong / browne ) 17:04:03 I can see the two guys above working on the projects, but a lack of core reviewers means patches are not landing. 17:04:47 I have been making an effort to get more busy on bandit and soon syntribios, but will take me some time to put in a lot of content of worth. 17:04:52 yeah, several months ago I asked the current cores of bandit if they still wanted to be involved. all of them wanted to remain cores, but i've seen no activity from them since 17:05:36 browne: ack, I could perhaps reach out to them as well. I guess most have seen their companies move on from openstack. 17:05:56 and then recently was talking with travis about whether we should move bandit to github (outside of the openstack domain) 17:06:43 browne: how many openstack projects have bandit running at their gate? 17:06:59 unsure 17:07:18 I know keystone has it as part of the pep8 gate, cinder has a non-voting one 17:07:23 quite a few though 17:07:25 dave-mccowan: is barbican running bandit still> 17:07:47 lhinds yes. i thought by making it part of pep8 gate that most projects are running it. 17:08:01 ah I see. 17:08:10 (or, maybe that was just a keystone thing.) 17:08:30 #action lhinds audit bandit use 17:08:30 I think a few other projects do the same 17:09:14 looks like barbican has it as part of pep8 17:09:26 so browne , its not my call of course, but in regard to porting to github, maybe we could see what we can make happen just over this cycle and if things don't improve, then its clear what to do. 17:10:18 sounds to me like its still in use a lot though, for example I did a depends-on patch today for python-keystoneclient. a small example ofc. 17:10:34 it could still be used by openstack projects 17:10:54 but my porting to github, might get more contributors 17:11:13 it has next to no openstack specific code anyway 17:11:21 and functions a lot like flake8 17:11:35 yep, I see your point. 17:11:51 i guess gate pulls it in from requirements.txt? 17:12:18 yeah 17:12:40 so we would just switch pypi from openstack tarballs, to github. 17:12:50 that's the other thing. i don't have the pypi user/pwd, so i can't push a new release to pypi 17:12:58 we would need to get that from travis 17:14:01 can’t that be done from the openstack release process? I 17:14:32 I don’t remember manually pushing a pypi release the last time we did it for syntribos 17:14:46 that's true ^ 17:15:04 oh ok, i've never done it myself. so maybe it's more automated 17:15:11 do you just create a tag? 17:15:39 I think there’s an openstack-releases repo 17:16:10 let me try to find the documentation 17:16:45 https://releases.openstack.org/instructions.html 17:17:10 pypi would pull from here: https://tarballs.openstack.org/bandit/ 17:17:30 I think(?) 17:17:37 that's normally how it happens 17:18:00 ok 17:18:58 so not sure how to go ahead here, I personally would like to try and see if we can improve contributions and stay in openstack, but at the same time its not my baby to be strongly viewed 17:20:03 browne I can try to devote some time to help reviews for bandit 17:20:26 me too, put a few patches up this week and last. 17:20:29 we need another core. i'm the only one reviewing 17:20:36 only thing is we need another ... ^ 17:21:25 heres what we can do, I will contact travis as I here from him occasionally and see if he can devote some time to +2's to allow a merge 17:21:48 he doesn't work on openstack anymore 17:21:58 works for netflix i believe 17:22:23 or we lower the barrier for bringing in some new cores? 17:23:17 and if things have not improved half way through the next release cycle, port to github? 17:23:42 how would that sound browne ? 17:23:49 sure 17:24:27 so perhaps myself and gagehugo could come on to help, we would mainly test each patch..and follow on from your +2's? 17:24:55 sounds good 17:25:00 works for me 17:25:39 great, I will get onto that. 17:25:56 are all ok, if we go past the 30 minute mark? 17:26:15 was thinking same issue is there for syntribios ( mdong )? 17:27:04 yeah, it’s a little better situation for core reviewers because I can still ping cneill for reviews if need be, even if he’s working on non-openstack projects 17:27:41 ok, that's good. I am monitoring the queue as well so will continue to help. 17:28:30 so for other topics, let me prioritise to the audience. dave-mccowan anything on barbican / PTG you wanted to cover? 17:28:41 we have custodia confirmed from last week. 17:29:22 https://etherpad.openstack.org/p/barbican-ptg-queens 17:29:46 that's the etherpad. please sign up if you plan to attend and add any topics you'd like to discuss. 17:29:58 thx dave-mccowan 17:30:08 browne: are you at the PTG? 17:30:31 unfortunately i won't make it. had already planned a vacation before knowing the dates for PTG 17:30:44 browne: no worries 17:30:55 would be nice if the PTG organizers released the dates earlier 17:31:05 browne agree 17:31:28 ok, will speed through the next bits.. 17:31:32 #topic OSSN 17:31:40 one one in review: https://review.openstack.org/#/c/499176/ 17:31:40 oh hai guys 17:31:46 oh hey hyakuhei ! 17:31:53 OSSN triggered my flag ;) 17:32:32 for security-docs, I have got the release notes in for Pike and updated the disclaimer text at the start. 17:32:39 looks like 81 is GTG ? 17:32:45 we also have the key management section we will go over at the PTG 17:33:04 raildo: anything on custodia? 17:34:16 for anyone interested there is a custodia session in the barbican room, and its going forward as an oslo driver 17:34:41 https://github.com/latchset/custodia 17:34:55 it solves the plain text passwords in config files issue 17:35:45 there's an oslo spec for that right? 17:35:47 ok, I think we can wrap up as we are over time..unless any other points / biz? 17:36:55 hyakuhei (thanks rgding 81, just seen your msg) 17:37:17 ok, thanks all..much appreciate you attending. 17:37:26 see you next week! 17:37:30 Cheers 17:37:35 sorry, I'm a little bit late 17:37:37 Does anyone have any experience with Custodia ? 17:37:47 Reads like a discount HC Vault ? 17:37:49 ok, lets go a little longer :P 17:38:03 oh it's more of an API 17:38:13 hyakuhei: raildo can give a 101 17:38:24 Meh, this isn't security project specific, call it if you want boss! 17:38:41 hyakuhei we used it as a middleware for storing plain-text values in barbican 17:38:53 oslo.config -> custodia -> barbican 17:38:58 interesting 17:39:17 hyakuhei: https://etherpad.openstack.org/p/oslo-ptg-queens 17:39:22 there are still unsolved issues, but it's a good step forward worth pursuing imo 17:39:27 *see " Pluggable drivers and Protecting Plaintext Secrets" 17:39:55 and the point is you can write drivers for other backends too, so you can s/barbican/vault 17:40:03 or w/e you like 17:40:37 hyakuhei, so, Custodia is basically an secrets-as-a-service API, to transport and routing secrets in a proper way, there is a storage layer abstraction, when Custodia support FreeIPA value, sqlite, etcd, and we add support to Barbican during integration work 17:40:54 raildo I'll try to get in the room for that oslo topic 17:41:11 gagehugo +1 17:41:24 also of interest to others might be 'Support for external PDP' 17:41:41 yeah I need to make myself a schedule heh 17:41:52 Sounds interesting, I wonder if it'll run into the same issues as Castellan around identity and how AuthN/Z gets messy with such abstractions 17:42:05 gagehugo, that's awesome, we are discussing with the tripleo team, to having the discussion related to the oslo.config stuff on it 17:42:27 raildo nice 17:43:46 i'd like to see Barbican as a consumer of Custodia. It would be a nice place for us to store the master KEK. (of course that wouldn't make much sense if we're also the backend) 17:44:00 hyakuhei, it's not, since Custodia works with pluggable authentication and authorization methods, actually, we don't want to use Keystone auth stuff, since we need to store keystone secrets either 17:44:17 Excellent 17:44:40 So it looks like a secrets abstraction layer, so you can write your software to talk "Custodia" and it takes care of plugging into x/y/z secrets management 17:44:48 Obviously useful for OpenStack 17:45:06 I wonder if it would be useful for Kube too, they're still working out how to do secrets management nicely. 17:45:15 hyakuhei, ++ 17:45:37 hyakuhei, we have the same Custodia support for docker and kubernetes 17:46:03 hyakuhei, that's the idea to have multiple backends for multiple purposes 17:46:22 Certainly sounds interesting :) 17:46:29 yeah that sounds interesting if it works with k8s 17:46:31 Thanks for the 101 17:46:50 hyakuhei, so, I'm looking for using Barbican for fit better on OpenStack scenario, but Custodia have a kind if multitenancy support, to having different auth and storage methods 17:47:06 hyakuhei, sure, anytime, I hope to explain it better in the PTG 17:47:53 cool, thanks raildo ! 17:48:18 ok, so lets close for now..but some good conversations today and thanks all for your attendance. 17:48:46 #endmeeting