14:05:20 #startmeeting OPNFV Security Group 14:05:20 Meeting started Wed May 6 14:05:20 2015 UTC. The chair is jaosorior. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:05:20 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:05:20 The meeting name has been set to 'opnfv_security_group' 14:06:07 still figuring out how the actions work in this 14:06:55 alright 14:06:57 I think you simply set the topic with the topic command, then we info about it 14:07:05 ah, fair enough 14:07:37 still figuring out what the next topic will be though, there is not much info in the etherpad 14:07:53 #topic agenda 14:07:53 I could bring up inspector stuff in a bit. Got anything on your side mwinandy? 14:08:00 #topic Agenda 14:08:33 some info about getting in touch with Moon 14:09:01 Alright, so I guess mostly we will touch Moon and then inspector, that sounds fair enough? 14:09:46 I am good with that 14:09:52 #agreed Agenda 14:10:02 #topic Moon 14:10:22 So, what's up mwinandy? 14:10:41 #info discussed with Ruan He (Orange) about how to contribute to Moon 14:11:20 Do you know if the main contributors to Moon will be in the OpenStack summit? 14:11:35 hm, don't know 14:12:07 #info they are preparing to revise the proposal 14:12:12 It would probably be appropriate to sync there 14:12:17 alright 14:12:53 What's missing from their proposal? 14:13:05 #info I had a look at a running demo of Moon. It supports RBAC and MLS access policies for users/tenants on OpenStack currently. 14:13:39 not clear what's missing, I'll try to find out :) 14:13:53 How does it relate to keystone? 14:14:29 #info Moon prototype code is currently standalone, but should be an extension for Keystone in next release. 14:14:33 And, do you know if Moon has its own timeslot for meetings? If not, maybe they should bring up some stuff here too 14:14:59 mwinandy: an extension for what? for the assigment or the identity backend? 14:15:16 or is it gonna replace the policy engine? 14:16:13 #info Moon will not replace policy engine, instead using existing one. But adds policy configuration and policy decision point. 14:16:30 I see 14:16:50 As you ask (and others) these questions, I think that is what should be added to the proposal and make more clear. 14:17:09 I think the best thing would be to try to get them involved in the security group, probably some people here will have questions 14:17:16 at least I do 14:17:34 yes, let's invite them to join 14:17:47 #action Invite the contributors to the Moon project to the next Security Group meeting 14:17:57 I think Moon can be an important part of the opnfv security architecture. 14:18:06 moon is not listed on opnfv meetings page 14:18:52 I'll send a mail to the list and openly invite them to the next meeting 14:19:11 mwinandy: thanks for the info. Anything else you wanna share regarding that? 14:19:23 #info OpenStack has a lot of modules, each with their own (security) config. Moon wants to build a centralized policy management for all things in OpenStack, SDN controller, etc. Also place hooks in those components that they can directly enforce dynamic changes in the policy. 14:20:10 * digging out a relevant link* 14:21:00 #link http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg52144.html 14:21:49 #info that is worth a read, one of the keystone core-devs gives a really good insight about how policy works and some relevant aspects to take into account 14:22:00 It would be very beneficial for the moon project if they properly sync with the guys from Keystone 14:22:00 good! 14:22:34 At least he agrees on the dynamic/centraliced policy 14:22:42 as stated: ") Making the policy centrally sourced (i.e. in keystone) and more dynamic seems eminently sensible." 14:22:48 I'm going to be involved, so I will take that. 14:23:00 Is there a link describing moon? 14:23:12 #link https://wiki.opnfv.org/moon 14:23:12 #link https://wiki.opnfv.org/moon 14:23:42 thanks 14:24:51 any other info/questions? 14:26:08 that's it from my side so far 14:26:26 Alright, thanks for the info 14:26:36 next topic 14:26:40 #topic inspector 14:26:48 There was an ETSI sec LI doc contribution out this morning...guess cannot share that though. 14:27:10 sorry, missed change in subject 14:27:29 B_Smith: we can touch that after this topic, it's the last one we had agreed on 14:27:57 #info The inspector project had a community review last Thursday, so it seemed that people agreed on the proposal 14:28:44 Luke had actually mentioned he would try to bring some ETSI people, as it would be very beneficial to sync requirements for inspector 14:28:50 for anyone interested: 14:29:02 #link https://wiki.opnfv.org/requirements_projects/inspector 14:29:42 hopefully next meeting we can sync with the Moon project, since probably some of the stuff that inspector will touch upon (at least on the OpenStack side) would be beneficial for Moon to use 14:30:36 and vice versa: if Moon changes policy settings, that should probably audited/logged as well 14:30:51 from the people here, besides aripie, who is intending to contribute to inspector? 14:31:11 I'm trying to get a colleague to contribute 14:31:48 mwinandy: that is correct, but we need to sit down with the Moon people, cause there are some considerations in regards to the auditting solution in OpenStack, and things that need to be done as a pre-requisite 14:32:23 so I want to figure out how the project will be set-up, and if it needs similar settings as the OpenStack modules do 14:32:49 or how do Moon intends to be "auditted" 14:33:06 would moon also decide on audit policy? 14:33:09 Since at the moment, most of the OpenStack operations auditting is directed towards the ceilometer event database 14:33:13 I think that point is missing in Moon, and I wanted to suggest to sync there, too 14:33:52 well, something we need to do is invite people to openly discuss inspector 14:34:08 we already agreed that we're gonna invite the moon contributors to the next meeting 14:34:14 so hopefully next week we can sync 14:34:19 so far moon considers authorization of objects, APIs etc. from that, looking at audit policy as an "object" you want to change, I think it should be part of it some how 14:34:33 #action invite the mailing list to discuss the inspector project 14:35:23 mwinandy: if it aims to be working with openstack, it would be beneficial for Moon to adopt some OpenStack ways of working. But it depends on the architecture that's planned and to many other things 14:35:39 Hopefully we can sync very soon and get these things clearer 14:35:53 because probably we don't have all the info 14:36:11 but also maybe they could benefit on re-using some of the things that are already in OpenStack 14:36:40 Anyway, regarding Inspector 14:37:22 We probably need a repo for some documents that will be generated, and there we would also document any relevant blueprints that come out of the project 14:37:53 my idea was to mostly work with git/gerrit, since it gives you the capability of commenting inline in the text 14:37:58 does that suit people? 14:38:56 as these are the typical tools, no objection from my side 14:39:05 aripie? 14:39:39 ok 14:39:47 ok 14:39:56 #action request the Linux Foundation for a repo for Inspector 14:40:20 Would people find it beneficial that I write an overview of how audit works in OpenStack at the moment as documentation in the repo? 14:40:34 yes 14:40:39 yes 14:40:41 I was planning to do that anyway, it's just a matter of where to put that: in the repo or in a separate blog post or something 14:41:03 better keep in the repo, refer to that from elsewhere 14:41:14 ok 14:41:35 #action jaosorior to write an overview of audit in OpenStack in the Inspector repo 14:41:56 #action set up a proper sphinx project structure in the repo 14:42:19 I guess we have to wait for Luke for the ETSI related stuff (regarding being in sync with their requirements too) 14:43:00 B_Smith: you and Ashutosh are in ETSI NFV, coould you get other relevant people join? 14:44:28 and the first thing that we need to come up with, is how actually test audit in an end-to-end fashion. So we need to come up with a proposal for either Tempest, or another solution such as Yardstick if Tempest is not sufficient (I'm still evaluating that) 14:46:13 Since at the moment there is no actual way to actually verify (in an actual test-case) that an audit event was properly logged 14:46:24 and that the taxonomies that already exist are sufficient 14:46:44 I will bring this up again next week anyway 14:46:47 and the integrity of the audit config 14:47:06 true 14:47:24 +1 for integrity :) 14:47:50 hahaha everybody is interested in integrity, hopefully we can bring it up soon. We also need to figure out the scope of integrity 14:48:09 Do 14:48:20 since, besides config integrity, we would be touching event-record integrity if it's actually needed in some requirements 14:48:29 it is 14:48:36 ok 14:48:43 I would still like to sync with ETSI first 14:48:56 just to know we're on the same page, or to know if we are missing something 14:49:14 since, once we get audit tests set up (which hopefully could become a test gate in openstack) 14:49:29 we will need to verify the content of the event records according to some standard 14:49:52 (or several) 14:50:25 #link http://www.etsi.org/technologies-clusters/technologies/nfv 14:50:26 I will be coming up with results soon. I got side-tracked since I found a little bug in ceilometer and started fixing it 14:50:44 I have nothing more for Inspector 14:50:47 do you aripie? 14:50:49 hmm. security bug? :) 14:50:52 the NFV-SEC docs are pretty good, but lack specifics of audit criteria 14:51:12 mwinandy: nah, some bug regarding displaying events, since it's the stuff I was looking at 14:51:59 nothing much more to say today on Inspector, let's hope a wider audience next time attending 14:52:05 anyway, I guess that's all for inspector 14:52:11 #topic any other business 14:52:17 B_Smith: you got anything? 14:54:48 Alright 14:54:56 I guess that's that 14:55:53 thanks then for today 14:56:03 #endmeeting