12:05:08 #startmeeting TripleO Security Squad 12:05:09 Meeting started Wed Jun 6 12:05:08 2018 UTC and is due to finish in 60 minutes. The chair is jaosorior. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:05:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:05:13 The meeting name has been set to 'tripleo_security_squad' 12:05:17 This time it was me being a bit late :D 12:05:27 no worries 12:05:41 lhinds, Tengu are you around? 12:05:44 #link https://etherpad.openstack.org/p/tripleo-security-squad 12:06:22 #topic Public TLS by default work update 12:06:56 As I mentioned yesterday in the TripleO weekly meeting, the public TLS by default work is currently blocked due to some decisions made about the approach we'll take to enable that. 12:07:11 The first iteration added that to the deploy mistral workflow 12:07:33 hey jaosorior , sorry was delayed 12:07:36 However, we decided to instead add that logic to the derive_parameters workflow, which is currently not enabled by default 12:08:00 dervie_parameters is currently used for NFV cases, where more info is needed to be dynamically added to the deployment depending on the hosts 12:08:03 but it could be generalized 12:08:27 jaganathan took on the work of making that workflow more general, and even adding the Fixed IP additions we need 12:08:56 He's working with the following patches 12:09:00 #link https://review.openstack.org/#/c/572678/ 12:09:05 #link https://review.openstack.org/#/c/572701/ 12:09:11 So please review them if you have some time 12:09:21 o/ 12:10:15 URGENT TRIPLEO TASKS NEED ATTENTION 12:10:15 https://bugs.launchpad.net/tripleo/+bug/1775205 12:10:16 https://bugs.launchpad.net/tripleo/+bug/1775209 12:10:17 Launchpad bug 1775205 in tripleo "Failing jobs are no longer getting the output from gate_test_oooq.sh script" [Critical,Triaged] - Assigned to Ronelle Landy (rlandy) 12:10:18 Launchpad bug 1775209 in tripleo "docker permission denied on upgrade prep containers" [Critical,Triaged] - Assigned to Steve Baker (steve-stevebaker) 12:10:18 After that work merges, we can add the code needed to get TLS by default in the overcloud on top of that 12:10:55 That's all on that side 12:11:07 Any questions/feedback? 12:12:16 #topic Limit TripleO users 12:12:25 I believe Tengu and lhinds have some updates on this topic 12:13:20 woops, sorry, late. 12:13:25 So Tengu plans to tackle stack user, while I will look at the heat-admin and other users. We also plan to work on a spec as first prior so that a consensus can be gained over the approach. 12:13:32 please add if you like Tengu 12:13:47 there is a ML thread with some good discussion 12:13:56 and giving oslo.privsep a look in 12:14:05 actually two threads, but yep. 12:14:08 (in tripleo pythonclient) 12:14:40 fact is, oslo.privsep isn't easy to tackle, and will require "some" refactoring - but it's all for the best. We really have to write the spec/blueprint first though 12:15:16 Tengu: what are the main limitations we have currently that prevent us from adopting oslo.privsep? 12:15:22 Following Michael blog posts we can reach a nice state. 12:15:56 jaosorior: well, at least in tripleoclient, the undercloud deploy is called with root - and there are many things that needs to be changed in order to launch it as a user. 12:16:41 mainly, there are file rights to change on the fly in the process, it starts heat daemon as heat and so on. for now, the code itself doesn't care about privileges, so there are os.chown, os.setuid and the like. 12:17:29 also a bunch of subprocess calls without any "sudo" or whatsover. So we will need to git-grep all of those occurences, check WHO has to run them, what are the requested rights, and finaly configure some privsep context. 12:17:39 Tengu: do we have a list of things we should change so we can track them and address them systematically? 12:17:44 that would probably be useful 12:17:58 we already have an etherpad where we were tracking this work. lhinds do you have the link? 12:18:15 yup: https://twitter.com/WHS_Carpet 12:18:20 derp! 12:18:22 one sec.. 12:18:26 lol 12:18:28 jaosorior: not really. I have a beginning of sudoers though, it might be a start. But using rootwrap (privsep) will change that 12:19:13 https://etherpad.openstack.org/p/tripleo-heat-admin-security 12:19:21 fact is, rootwrap is "just" a sudo filter so that we don't have to manage the listing directly in sudo. also, it allows a more fine-grained right management. 12:19:28 #link https://etherpad.openstack.org/p/tripleo-heat-admin-security 12:19:42 #link https://www.madebymikal.com/how-to-make-a-privileged-call-with-oslo-privsep/ 12:19:49 #link https://www.madebymikal.com/adding-oslo-privsep-to-a-new-project-a-worked-example/ 12:20:04 those two blogposts are really interesting and put some good practices/ideas. 12:20:14 OK, I'll take a look at those 12:20:26 it might be interesting to involve Michael Still in "our" spec writing 12:20:56 so the above would cover python code, but we also need to agree an approach on general nix scripts and calls using 'sudo ' 12:20:58 as it seems it's a pretty young thing, it's the good time to write a precise spec and implement best practices for privsep use 12:21:02 Tengu: is the spec you're referring to limited to the undercloud's stack user? or will it be a general approach for the overcloud user as well? 12:21:23 Rafael Folco proposed openstack-infra/tripleo-ci master: Move scenario000-multinode-oooq-container-upgrades to check https://review.openstack.org/572187 12:21:48 jaosorior: I think we should write two specs: one regarding general python coding style regarding privileges escalation; a second regarding "standard sudo calls from a shell" 12:22:01 lhinds: -^ this also answers your concern I think :). 12:22:17 OK 12:22:27 I see those two issues as different issues - so different specs. 12:22:34 That would work, we just need to make sure we co-ordinate the patches for when we switch off :ALL 12:22:46 lhinds: of course we have to. 12:22:47 two issues that are coverd by this overall topic though :D 12:23:01 jaosorior: yep. but it's best to cut it in smaller parts. 12:23:07 else we won't find a start nor an end. 12:23:17 and yes, use the same topic / branch name (if that would work) 12:23:38 Tengu: agreed 12:23:49 lhinds: I've never done a spec/blueprint, care to start it somewhere (already on the etherpad I think) and I add my inputs? 12:24:20 Tengu: sure, its quite simple..will kick something off 12:24:26 Tengu: the etherpad is a good place to brainstorm and track things. you can even put a draft of the spec and subsequently propose it 12:24:31 lhinds: thank you :). 12:24:39 jaosorior: will see to that. 12:24:59 Alright, that will cover then python privilege escalation 12:25:04 I was thinking we could do a BP with two different specs 12:25:22 I will get onto that, leave it with me. 12:25:24 lhinds: that sounds like a good idea 12:25:36 John Trowbridge proposed openstack-infra/tripleo-ci master: Add ability to upgrade FROM change under test https://review.openstack.org/572419 12:25:37 John Trowbridge proposed openstack-infra/tripleo-ci master: Add logic/tests for n->n+1 upgrades https://review.openstack.org/572420 12:25:40 lhinds: forward the links, and we can work on that. 12:25:52 Tengu: ack, will do 12:25:54 Regarding scripts and sudo usage, lhinds, wanna share the proposal? 12:27:08 as said - we should write a dedicated spec for that, and enforce it in order to drop that horrible NOPASSWD:ALL :). 12:28:01 yup, so I have a basic script to pull out all sudo calls. Plan is to get this runnning in the various project test suites (tempest) and build a whitelist of calls that are made. 12:28:16 there's a thread about that in the ML, and the etherpad also gives some info - we have to format all of that and separate "python privilege escalation" and "privilege escalation with sudo in scripts". 12:28:42 So the spec will outline how to gather sudo calls (on-going) and regexp strictness needed for whitelisting calls. 12:29:01 +42 12:29:03 and also put together some playbooks that can apply the whitelists 12:29:36 hmm. would it make sense to add sudoers snippets in packages directly? 12:29:51 packages? 12:30:08 err. right, containers now, packages will drop. 12:30:18 sorry, yes... 12:30:35 spoke to jaosorior , it would be made within the image (vm / container) 12:30:45 Tengu: well, each openstack project already has some sudoers files specific to the project. The main concern here is the heat-admin or tripleo-admin users which we use for the deployment, and the validations user which we use for...well, validations :D 12:31:10 jaosorior: as well as "stack" user I guess (on the undercloud) 12:31:26 I saw some concern regarding its extensives rights on some sites. 12:32:04 Tengu: well, yeah, although ideally the stack user should only be able to do openstack commands, which we will then limit 12:32:32 or the minimum set of calls to set up an undercloud 12:32:39 it's worth noting that even if you lock down e.g heat-admin for the nodes, all API actors on the undercloud are admin, e.g you can always run arbitrary ansible tasks on the nodes even if you lock down the default user provided via the user-data 12:32:43 actually that's a good point.. the stack user has a lot of sudo calls for hiera work and others. 12:32:45 it's actually more or less the case - there are some needs for yum install - all the rest should be managed by privsep in python. 12:33:00 bah, we should manage that with user GROUPS 12:33:06 so spec needs to be on 'python' mgmt of escaltions, and script management 12:33:14 rather then stack / heat admin 12:33:18 i.e. hieradata owned by root:deploy - stack member of deploy group, and 0640 on the data. 12:33:21 or underclooud /overcloud 12:33:22 not saying a bad idea, only that it's a small part of the overall picture with an admin-driven provisioning/management tool 12:33:42 yup. that's why we need some proper specs. 12:33:54 in order to ensure we cover the cases, step by step. 12:34:23 file ownership can also be a (good) solution in some cases in order to avoid so-called privilege escalations. 12:34:53 Chandan Kumar proposed openstack/tripleo-quickstart-extras master: use upstream git url instead of github https://review.openstack.org/572347 12:35:26 I'm trying (unsuccessfully for now) to test the TripleO all-in-one installer on a VM running on my laptop. So far I'm getting http://paste.openstack.org/show/722798/ and the deployment fails. Does that ring a bell? 12:36:06 Tengu, lhinds: can you sync up in order to write the needed specs? It would be beneficial to have these discussions in the spec, for easier tracking. 12:36:11 jpena: the error seems actually above, not the hiera thingy. nothing before that error? 12:36:19 jaosorior lhinds sure thing. 12:36:29 jaosorior: agree, lets trash the finer points in review 12:36:46 Tengu, lhinds: Thanks for taking a look at this work 12:36:51 np 12:37:44 shardy: you'll be added to the spec reviews. your feedback is always very useful :D 12:38:19 jaosorior: ack thanks 12:38:25 Arx Cruz proposed openstack/tripleo-quickstart master: Using session in get-overcloud-nodes.py https://review.openstack.org/572709 12:40:12 Any more thoughts/feedback/questions about this? 12:41:59 Tengu: checking 12:42:05 #topic Any other business 12:42:20 Anything else folks want to bring up to the meeting? 12:42:28 yep 12:42:44 me and raildo are making progress with the secrets stuff 12:42:57 moguimar: can you share a bit of context for the rest of the atendees? 12:43:15 we're implementing backend drivers for oslo.config 12:43:34 to store plaintext secrets elsewhere other than in the plaintext config files 12:43:44 #link http://specs.openstack.org/openstack/oslo-specs/specs/queens/oslo-config-drivers.html 12:44:18 the oslo.config work consists of supporting drivers and an INI driver for fetching config from an URL 12:44:32 then we'll add a driver for castellan 12:44:49 so oslo.config will be able to retrieve sensitive config from castellan 12:45:00 after that, we'll try to integrate to tripleO 12:45:25 right now we're 80% done in the oslo.config and starting the work on castellan 12:45:38 anything you want to add raildo ? 12:45:55 would also be nice to bring doug to this meeting next week 12:46:04 Yeah, that would be useful 12:46:54 so, would be great review this current spec: https://review.openstack.org/#/c/474304/ where we should define how that integration with tripleO will be done, probably target release 12:47:04 so, any review on that aspect will be appreciated :) 12:47:39 raildo: will read it at least. no +2 from me thoug - can't do that :). 12:48:00 Tengu, haha thanks :) 12:48:38 raildo: I'll check that spec out, however, once we have a bit more details on how the deployment would look like; it would be better to propose a separate spec just for TripleO integration 12:49:10 Luke Hinds proposed openstack/tripleo-specs master: [WIP] Spec placeholder for limit sudo BP https://review.openstack.org/572760 12:49:22 jaosorior, sounds reasonable for me 12:49:50 raildo: lhinds just uploaded a spec placeholder, so you could use that for reference :) ^^ 12:49:57 lhinds: just added myself on your placeholder. 12:50:13 awesome, thanks for the hints! 12:50:17 moguimar, raildo: Do you have an estimate on when you'll finish the castellan driver? 12:50:23 Tengu: cool, there will be another coming for pything stuff 12:50:28 so we can start thinking about TripleO integration 12:50:33 s/pything/python 12:50:59 not yet 12:50:59 jaosorior, so, the castellan driver will be target for early on Stein release 12:51:17 OK 12:51:23 but not so well defined right now 12:51:24 tks raildo 12:51:55 so basically, that's no worries about that on Rocky, we can start discussing about that on PTG-ish 12:52:10 sure 12:53:20 raildo, moguimar: Do you want to use next week's meeting to brain storm about TripleO integration? 12:53:31 jaosorior, that would be awesome! 12:53:53 OK, I'll write it up as a topic for next week's meeting 12:53:57 lets hope redrobot can make it 12:54:15 raildo, moguimar: thanks for driving this effort 12:54:41 no problem :) 12:55:08 any questions/feedback on this work? 12:55:44 raildo: just read your spec. Pretty nice :). Added a comment for tripleo integration "needs" - I'm a beginner on that topic, so there's possibility I missed something :) 12:56:08 Luke Hinds proposed openstack/tripleo-specs master: [WIP] Spec to improve privilege mgmt in py-client https://review.openstack.org/572761 12:56:34 lhinds: cool :) 12:56:35 Tengu, thanks , I'll take a look on that soon! 12:56:52 so both have the same topic now: 12:56:54 https://review.openstack.org/#/q/topic:priv-mgmt+(status:open+OR+status:merged) 12:57:02 we can use the same topic for patches as well 12:57:06 (easier to track) 12:57:22 lhinds: awesome! 12:57:26 don't worry about naming and stuff, we can fix that up 12:57:55 Tengu: you can cherry pick the spec down and take over as author or co-author etc. 12:58:08 or just leave as it is, up to you mate 12:58:08 Well, we're at the end of the meeting now 12:58:12 lhinds: pl 12:58:12 thanks to everybody for attending 12:58:15 *ok 12:58:17 thanks jaosorior 12:58:22 thanks ozz 12:58:33 #endmeeting