13:00:37 <lhinds> #startmeeting security-squad 13:00:38 <openstack> Meeting started Wed Mar 14 13:00:37 2018 UTC and is due to finish in 60 minutes. The chair is lhinds. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:00:41 <openstack> The meeting name has been set to 'security_squad' 13:00:41 <jaosorior> thanks lhinds 13:00:46 <lhinds> #chair jaosorior 13:00:47 <openstack> Current chairs: jaosorior lhinds 13:00:47 <raildo> o/ 13:00:53 <lhinds> hey raildo 13:01:00 <jaosorior> Lets wait some minutes for more folks to show up 13:01:05 <raildo> hey lhinds, what's up? 13:01:26 <lhinds> good thanks raildo , ack jaosorior 13:03:34 <dprince> mandre: +2 from me here https://review.openstack.org/#/c/515490/ 13:03:38 <dprince> honza: ^^ 13:04:03 <honza> nice, thanks 13:04:09 <dprince> mandre, honza: patch is in the ballpark. Lets get it in as having it would be helpful to a few teams at this point 13:04:10 <jaosorior> lhinds: well, maybe we can start. 13:04:20 <lhinds> #link https://etherpad.openstack.org/p/tripleo-security-squad 13:04:24 <jaosorior> #topic Proposal/Work item (continued from last meeting) 13:04:29 <alee> o/ 13:04:30 <openstackgerrit> Merged openstack/tripleo-common master: add option --gather-facts https://review.openstack.org/548651 13:04:34 <lhinds> hey alee 13:04:37 <honza> dprince: yes, that's what i thought --- let's fix any issues as they come up 13:04:42 <alee> lhinds, morning 13:04:51 <jaosorior> So, continuing last week's meeting, we were going through the Work items/proposals 13:05:30 <openstackgerrit> Jose Luis Franco proposed openstack/tripleo-upgrade master: New major upgrade workflow implementation. https://review.openstack.org/548336 13:05:31 <openstackgerrit> Jose Luis Franco proposed openstack/tripleo-upgrade master: [DNM]: Apply workaround for P->Q upgrades. https://review.openstack.org/549220 13:05:38 <jaosorior> there were namely two left: TripleO Threat Analysis and Limit TripleO users 13:05:50 <jaosorior> lhinds: any preference on whic to talk about first? 13:06:03 <lhinds> can go in the order you said them. 13:06:11 <jaosorior> OK 13:06:19 <jaosorior> #topic TripleO Threat Analysis 13:06:42 <lhinds> so this is for us to chew over, and will need an discussion on the ML too. 13:07:05 <jaosorior> lhinds: how is this normally done in the Security SIG? 13:08:06 <lhinds> In the Security SIG we offer threat Analysis for projects. This consists of a series of steps, such as the architecture is laid out, and we then start to walk through a series of questions to look for weaknesses in endpoints, auth, access control. 13:08:29 <lhinds> We did this for Barbican before, and the result was a CVE was raised, so it well worthwhile. 13:08:44 <lhinds> Once a TA is complete, a project can then be VMT managed 13:08:58 <lhinds> VMT = vulnerabilty management team. 13:09:17 <lhinds> This means if an issue is found, it can be dealt with 'under embargo' 13:09:43 <alee> lhinds, have any other teams taken advantage of this? 13:09:54 <lhinds> so that way downstream stakeholders have a window to prepare patches without their systems being at risk between the time of exposure and patching. 13:10:15 <lhinds> alee: Barbican is one, we also just did Keystone middleware client 13:10:16 <ooolpbot> URGENT TRIPLEO TASKS NEED ATTENTION 13:10:16 <ooolpbot> https://bugs.launchpad.net/tripleo/+bug/1754036 13:10:17 <openstack> Launchpad bug 1754036 in tripleo "fs020, tempest, image corrupted after upload to glance (checksum mismatch)" [Critical,Triaged] 13:10:20 <lhinds> a number of others too. 13:10:58 <lhinds> so as I say, it is a uncovering process and results in VMT covereage. 13:11:34 <lhinds> I know tripleo has downstream coverage in RH for vulns, but they won't handle anything upstream that has not yet landed in a downstream release. 13:12:45 <lhinds> that's essentially it 13:13:17 <jaosorior> well, I think it would be beneficial for TripleO. As you mentioned, perhaps the best way to start is to propose it in the mailing list, could you do that? 13:13:22 <lhinds> it then needs an architect in tripleo, and someone in the SIG (that can be me), but I can help with both 13:13:35 <lhinds> jaosorior: I agree. Let me take that as an action 13:13:37 <openstackgerrit> Merged openstack/instack-undercloud master: Remove cloud-init and disable os-collect-config https://review.openstack.org/550966 13:13:38 <openstackgerrit> Merged openstack/tripleo-heat-templates stable/queens: DPDK deployment fails when there is no deprecated parameters https://review.openstack.org/552304 13:13:44 <rlandy> mwhahaha: the reproducer I ran using the promotion master and https://review.openstack.org/#/c/552693/ failed to install the undercloud 'oslo_config.cfg.NoSuchOptError: no such option 1350 in group [DEFAULT]. I see the gates passed though 13:13:48 <lhinds> #action lhinds to mail ooo ML about TA 13:14:16 <jaosorior> lhinds: I'm also interested in taking part of the TA; and hopefully the mailing list proposal will get other folks interested as well. 13:14:34 <lhinds> jaosorior: yep 13:14:35 <jaosorior> shardy: I know you have a lot on your plate, but would you be interested in taking part? ^^ 13:15:30 <openstackgerrit> Merged openstack/tripleo-ui stable/queens: Add nova to appConfig immutable record https://review.openstack.org/552825 13:15:47 <jaosorior> well, maybe he'll answer later. 13:15:51 <jaosorior> lhinds: anything else in that topic? 13:16:09 <lhinds> jaosorior: that's it for now 13:16:34 <jaosorior> lets move to the next item then. 13:16:37 <openstackgerrit> Lukas Bezdicka proposed openstack/tripleo-heat-templates master: FFU: Fix gnocchi FFU tasks https://review.openstack.org/548635 13:16:43 <jaosorior> #topic Limit TripleO users 13:16:59 <openstackgerrit> Lukas Bezdicka proposed openstack/tripleo-heat-templates master: FFU: Introduce post FFU steps and use them for qeens switch https://review.openstack.org/547785 13:17:13 <jaosorior> lhinds: you were gonna start working on this at some point soon, right? 13:17:19 <lhinds> So this one is essentially around the sudo levels avaliable to stack, heat-admin and validations. 13:17:36 <lhinds> jaosorior: hope to start the later point of this week. 13:18:01 <lhinds> some users such as validations have WHEEL (ALL):NOPASSWD 13:18:29 <EmilienM> lol bandini the rebel 13:18:45 <lhinds> so that means they can do `sudo su`, or `sudo rm -rf --no-preserve-root /` 13:18:54 <jaosorior> :( 13:18:55 <lhinds> a lot of power. 13:19:18 <lhinds> so the result of the audit will mean we instead limit `sudo` use to specific commands / actions. 13:19:53 <lhinds> also we will look for passwords, private keys... 13:20:04 <openstackgerrit> Merged openstack/python-tripleoclient master: Update the doc links to the right ones https://review.openstack.org/535217 13:20:06 <openstackgerrit> Merged openstack/tripleo-heat-templates master: Minor update steps for ODL https://review.openstack.org/536907 13:20:07 <lhinds> in places such as hieradata, enviroment files etc. 13:20:14 <openstackgerrit> Merged openstack/tripleo-heat-templates master: Convert ServiceNetMap evals to hiera interpolation https://review.openstack.org/526692 13:20:36 <lhinds> thats mainly it 13:20:49 <openstackgerrit> Lukas Bezdicka proposed openstack/tripleo-heat-templates master: FFU: Fix Cinder services action order https://review.openstack.org/548633 13:21:12 <jaosorior> I guess the best way to start is to come up with the list of users and proposed privileges 13:21:13 <alee> lhinds, and metadata .. 13:21:21 <lhinds> alee: yep, ack! 13:21:42 <jaosorior> should we set up an etherpad to collaborate on such list? 13:22:18 <lhinds> jaosorior: yep..let me do it now quickly so we can get it in the minutes. 13:22:24 <jaosorior> great 13:22:51 <lhinds> #link https://etherpad.openstack.org/p/tripleo-audit-limit-track 13:22:52 <alee> lhinds, would the eventual idea be to identify the "red, yellow and green" users and feed those into the security hardening ansible modules? 13:23:00 <openstackgerrit> Dmitry Tantsur proposed openstack/tripleo-common master: Rework set_provision_state/set_power_state workflows https://review.openstack.org/552554 13:23:03 <dtantsur> d0ugal: that's what I ended up with ^^^ 13:23:06 <dtantsur> will test after lunch 13:24:12 <jaosorior> alee: how is that usually done in openstack-hardening (the ansible module)? 13:24:18 <lhinds> alee: don't have a category plan yet, but changes would go into master / releases rather then be a seperate hardening action. We could then possible have a tag to in oooq to allow developers to get a looser environment for debugging 13:25:09 <lhinds> we can flesh out the approach in the etherpad 13:25:15 <jaosorior> sounds good to me 13:25:15 <alee> ack 13:25:16 <lhinds> so feedback / ideas welcome 13:26:06 <jaosorior> anything else someone would like to add on this topic? 13:26:58 <jaosorior> #topic Public TLS proposal work status 13:27:23 <jaosorior> I started doing some work on enabling TLS by default 13:27:36 <jaosorior> note that the proposal is for public TLS only 13:27:53 <jaosorior> I sent a notice about it to the mailing list 13:27:55 <jaosorior> #link http://lists.openstack.org/pipermail/openstack-dev/2018-March/128252.html 13:28:10 <openstackgerrit> Marius Cornea proposed openstack/tripleo-upgrade master: WIP: Add Ceph upgrade steps for FFU https://review.openstack.org/552114 13:28:13 <jaosorior> And proposed some patches for the undercloud already 13:28:29 <jaosorior> #link https://review.openstack.org/#/q/topic:public-tls-default+(status:open+OR+status:merged) 13:28:38 <jaosorior> So, if folks have time to review those, it would be appreciated 13:29:09 <openstackgerrit> Dan Prince proposed openstack/tripleo-heat-templates master: Set TripleoUI bind_host via ServiceNetMap https://review.openstack.org/552879 13:29:18 <jaosorior> The remaining items there are: the overcloud and the containerized undercloud 13:29:49 <lhinds> sounds good jaosorior 13:29:57 <jaosorior> For the overcloud we would require a mistral workflow that would create the cert and create the necessary yaml files (this way it would work with the UI as well) 13:30:04 <alee> jaosorior, so this is using self signed certs unless ipa is around? 13:30:26 <alee> jaosorior, or using the certmonger local ca? 13:30:34 <jaosorior> alee: certmonger's local CA 13:30:50 <jaosorior> that would be the default 13:30:55 <alee> ok 13:31:07 <jaosorior> of course, folks can provide their own cert, or use FreeIPA if needed. 13:31:20 <jaosorior> that's still there. 13:31:44 <jaosorior> Also, help is welcome, so if someone wants to contribute to this work, please let me know 13:32:26 <lhinds> #help jaosorior looking for people to help with Public TLS 13:33:10 <jaosorior> any questions/feedback ? 13:34:06 <alee> jaosorior, this may be into the weeds a bit, but why mistral instead of ansible? 13:34:56 <jaosorior> alee: we would need to set the regular enable-tls.yaml templates before heat is called (which gathers and generates the ansible tasks) 13:35:22 <alee> ok 13:35:42 <jaosorior> alee: also, the UI doesn't call ansible directly. As far as I've understood, they rely on mistral workflows. 13:36:56 <openstackgerrit> Janki Chhatbar proposed openstack/tripleo-heat-templates stable/queens: Minor update steps for ODL https://review.openstack.org/552903 13:37:01 <alee> jaosorior, as I've been delving lately into the mistral workflows, I can probably help out with this one. 13:37:08 <jaosorior> that would be great 13:37:26 <jaosorior> Another thing to consider is, do we want to allow folks to deploy without TLS? 13:38:01 <janki> Hi. I can please get reviews for https://review.openstack.org/#/c/552903/. its a cherry-pick 13:38:03 <jaosorior> that would probably also need to be taken into account in the resulting workflow. 13:38:09 <alee> is ipsec just for internal tls? 13:38:37 <gunix> shardy: are you around? 13:38:39 <jaosorior> alee: the current IPSec solution is an alternative to encrypt the internal traffic. 13:38:59 <gunix> remember i was bitching a few days ago that bt-ctlplane didn't get an IP after the reboot and that openstack api was not working? 13:39:03 <gunix> shardy: ^ 13:39:04 <jaosorior> so yeah, right now it's only meant for the internal network 13:41:00 <alee> seems like a good ML item .. 13:41:00 <jaosorior> alee: wasn't planning on proposing that as a default, since it's for more specific cases. 13:41:08 <jaosorior> alee: true that. 13:41:09 <shardy> gunix: Hi, yes I remember 13:41:27 <gunix> shardy: the resolution was just using ip addr add to add the ip to the bridge 13:41:32 <jaosorior> #action jaosorior to ask for feedback in the ML about allowing deployments without TLS 13:41:33 <gunix> well, to the port 13:42:13 <shardy> gunix: Ok, could it be you have a problem with your config applied via os-net-config which that works around? 13:42:17 <shardy> sounds like it? 13:42:48 <jaosorior> #topic Secret identification for TripleO session proposal (for the Secret Management work item) 13:42:50 <openstackgerrit> Emilien Macchi proposed openstack/tripleo-heat-templates master: [CVE-2018-1000115] memcached: restrict to TCP & internal_api network https://review.openstack.org/551292 13:43:39 <jaosorior> Similarly to the "Limit TripleO users" item mentioned earlier, the "Secret Management" item needs us to do an audit and identify the deployment's secrets before coming up with a strategy to secure them 13:43:52 <jaosorior> I created an etherpad to follow through with this https://etherpad.openstack.org/p/tripleo-audit-secrets 13:44:01 <jaosorior> #link https://etherpad.openstack.org/p/tripleo-audit-secrets 13:44:02 <d0ugal> dtantsur: looks good! I think the "return" value for a workflow might be different. So I am not 100% the break-on will work, but if you have tested that already then it is fine. 13:44:09 <gunix> shardy: i have no idea what os-net-config does 13:44:32 <gunix> shardy: i followed the default tutorial for deploying undercloud, than rebooted, than noticed the issue 13:44:40 <jaosorior> To folks interested in this item: 13:44:55 <gunix> shardy: should i open any bug for this? I also have the resolution (adding the ip) 13:44:57 <jaosorior> should we schedule a time to go through the deployment and identify the sensitive data? 13:45:02 <openstackgerrit> Dan Prince proposed openstack/tripleo-heat-templates master: Set TripleoUI bind_host via ServiceNetMap https://review.openstack.org/552879 13:45:12 <gunix> shardy: well there probably is a proper way of solving this (making it reboot-persistent) 13:45:13 <jaosorior> or should we work on it async? 13:45:37 <lhinds> jaosorior: I can certainly try to help 13:45:49 <alee> ditto 13:46:13 <jaosorior> lhinds, alee great. So, do you guys wanna work on it async? or should we schedule a time to go through this together? 13:46:19 <shardy> gunix: os-net-config is the tool we use to do network configuration 13:46:37 <shardy> gunix: sure please raise a bug with as much detail, so we can figure out if it's a bug or a misconfiguration, thanks! 13:47:00 <gunix> shardy: where do i raise the bug? 13:47:18 <shardy> gunix: https://bugs.launchpad.net/tripleo/ 13:47:21 <lhinds> jaosorior: I am not sure, I might not be able to lead much on this one, but will make best efforts to help out where its needed 13:47:25 <dtantsur> d0ugal: I will test it soon, yes. I also have doubts about return values 13:47:27 <alee> jaosorior, I'm good either way -- a quick meeting not be a bad idea to identify areas to look at. 13:47:37 <moguimar> jaosorior: async is fine for me 13:47:53 <alee> which we could go back and work on individually 13:48:06 <shardy> gunix: please attach your undercloud.conf (sanitized of any sensitive data) and /etc/os-net-config/config.json, as well as the manual changes you made 13:48:07 <lhinds> +1 13:48:12 <jaosorior> alright 13:48:15 <jaosorior> sounds good to me 13:48:29 <jaosorior> a quick meeting to identify main areas, and from there work async on the etherpad 13:48:36 <moguimar> +1 13:49:11 <jaosorior> #topic Any other business 13:49:32 <lhinds> nothing from me 13:49:34 <jaosorior> Anything else that folks would like to bring up to the meeting? 13:49:42 <moguimar> me neither 13:50:12 <jaosorior> alright 13:50:16 <jaosorior> thanks for joining folks! 13:50:20 <jaosorior> #endmeeting