12:01:14 <jaosorior> #startmeeting Tripleo Security Squad
12:01:16 <openstack> Meeting started Wed Apr 18 12:01:14 2018 UTC and is due to finish in 60 minutes.  The chair is jaosorior. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:19 <openstack> The meeting name has been set to 'tripleo_security_squad'
12:01:25 <jaosorior> Alright, gonna wait for folks to join in
12:01:30 <moguimar> o/
12:01:39 <jaosorior> hey moguimar! how's it going?
12:01:44 <moguimar> fine
12:01:48 <jaosorior> lhinds-, alee, raildo: ping
12:02:04 <raildo> o/
12:03:49 <jaosorior> \o
12:04:52 <moguimar> https://etherpad.openstack.org/p/tripleo-security-squad
12:05:19 <jaosorior> Alright
12:05:24 <jaosorior> thanks moguimar
12:05:36 <jaosorior> #topic Storyboard migration
12:05:53 <jaosorior> So, last week we agreed to try out migrating to storyboard
12:06:05 <jaosorior> for which moguimar did us the favor of setting up a board and relevant columns for it
12:06:15 <jaosorior> #link https://storyboard.openstack.org/#!/board/65
12:06:54 <moguimar> the thing is, in order to create stories and tasks, they must belong to a project
12:07:05 <moguimar> and we don't have permission to create projects
12:07:14 <jaosorior> However, we stumbled upon the issue that in order to create a task in a story, we need to assign that task to a repo
12:07:25 <jaosorior> right
12:07:37 <moguimar> openstack-infra/tripleo-ci, openstack/tripleo-ui, openstack/tripleo-validations
12:07:41 <jaosorior> and not all TripleO deliverables are available in Storyboard
12:07:49 <jaosorior> at least not the ones that we're currently working with
12:07:49 <moguimar> these are the only tripleo-* projects so far
12:07:54 <jaosorior> right
12:08:32 <lhinds-> sorry all
12:08:34 <jaosorior> So, fungi suggested we create a provisional repository for the security squad; where we would add relevant documentation, and towards which we could assign the tasks we're tracking
12:08:51 <lhinds> o/
12:08:58 <jaosorior> hey lhinds! glad you could make it
12:09:05 <jaosorior> Anyway
12:09:13 <moguimar> something like openstack/tripleo-security?
12:09:16 <jaosorior> right
12:09:21 <moguimar> or 'tripleo-sec'
12:09:32 <jaosorior> however, mwhahaha wasn't to keen on the extra repo idea, since it does incur extra overhead (this new repo)
12:09:42 <jaosorior> and it's pretty much just for administrative (storyboard) purposes
12:09:52 <jaosorior> so, I can definitely understand that point
12:10:15 <ooolpbot> URGENT TRIPLEO TASKS NEED ATTENTION
12:10:15 <ooolpbot> https://bugs.launchpad.net/tripleo/+bug/1764870
12:10:16 <openstack> Launchpad bug 1764870 in tripleo "Missing tags in dockerhub, impossible to deploy a containerized undercloud" [Critical,Triaged] - Assigned to Gabriele Cerami (gcerami)
12:10:27 <jaosorior> so now it seems we have two options:
12:10:35 <jaosorior> 1) try to get that extra repository
12:10:47 <jaosorior> 2) pospone the storyboard migration
12:10:58 <jaosorior> * postpone
12:11:17 <jaosorior> What do you think?
12:11:31 * mwhahaha votes postpone
12:11:42 <moguimar> does every story we have touches a single repo?
12:11:55 <jaosorior> moguimar: no, they cross repos all the time
12:12:12 <jaosorior> moguimar: however, stories can have tasks that span several repos
12:12:17 <raildo> if that storyboard migration is not so urgent, we can postpone for a few weeks
12:12:19 <jaosorior> that's not the problematic part
12:12:34 <jaosorior> the problematic part is that we would then need ALL tripleo deliverables to be tracked by storyboard
12:12:43 * moguimar votes extra repo
12:13:03 <moguimar> the story itself points to the repo
12:13:22 <moguimar> but I'm not sure if the tasks under a certain story can point to other repos
12:13:31 <jaosorior> moguimar: they do
12:13:39 <lhinds> I am warming to a repo too, considering your last comment jaosorior
12:14:29 <moguimar> we might migrate to option two when the adoption is complete
12:14:36 <jaosorior> moguimar: try to add a story: you'll see that a story consists of a story title, the description, and below are the tasks
12:14:41 <jaosorior> the tasks then are map to different repos
12:14:49 <jaosorior> one task per-repo
12:14:55 <moguimar> but we might get stuck if we postpone for a while and then need another repo that is not migrated yet
12:14:55 <jaosorior> kind of
12:15:03 <jaosorior> moguimar: correct
12:15:21 <jaosorior> mwhahaha: is there any intention on moving all the TripleO deliverables to storyboard?
12:15:39 <mwhahaha> eventually that's what upstream wants
12:15:39 <openstackgerrit> Athlan-Guyot sofer proposed openstack/puppet-tripleo master: Prevent change in host parameter for nova/neutron/ceilometer.  https://review.openstack.org/555732
12:15:53 <mwhahaha> the hope was to move squads but since it requires specific repos
12:15:57 <mwhahaha> i'm not sure on the timing
12:16:02 <jaosorior> right
12:16:05 <moguimar> you're right, the story isn't project dependant
12:17:13 <jaosorior> one option I see is to use tripleo-docs. Since either way we need to document the feature work, and security considerations we come up with
12:17:16 <moguimar> can a task be reassigned to another project?
12:18:01 <openstackgerrit> Yurii Prokulevych proposed openstack/tripleo-upgrade stable/queens: Fix typo in inventory's output file.  https://review.openstack.org/562170
12:18:02 <lhinds> jaosorior: we have a security section in tripleo-docs
12:18:59 <jaosorior> lhinds: right, that's what I had in mind. I'm just not entirely sure what that actually means. I wouldn't want the Security Squad to "own" tripleo-docs... so hopefully it's just that the project is tracked and we can assign tasks for that repo.
12:19:06 <jaosorior> mwhahaha: any idea how that goes?
12:19:21 <lhinds> jaosorior: ack, see what you mean
12:19:28 <mwhahaha> that'd probably work as a workaround
12:19:40 <mwhahaha> can you move the bugs later from tripleo-docs?
12:19:49 <jaosorior> I hope so :D
12:19:52 <mwhahaha> :o
12:20:07 <mwhahaha> well that'd be a good workaround so we don't have to create a new repo for all the squads
12:20:07 <moguimar> but then we'll have to filter what needs to be moved
12:20:15 <mwhahaha> i don't think we have any docs bugs
12:20:25 <mwhahaha> so anything assigned to tripleo-docs would get moved i guess
12:20:28 <moguimar> bugs/tasks
12:21:02 <moguimar> then what if another squad has the same idea? "hey, lets use tripleo-docs"
12:21:15 <jaosorior> moguimar: hopefully they can use it as well
12:21:22 <jaosorior> that's what we need to figure out haha
12:21:25 <jaosorior> So, lets do this
12:21:31 <moguimar> then we will have to filter what is ours and what is not
12:21:52 <moguimar> what is the cost of having our own repo?
12:22:01 <jtomasek> d0ugal: yes, I belive so
12:22:21 <jaosorior> moguimar and me could poke EmilienM, and the storyboard folks for the following: 1) Is using tripleo-docs an option? 2) if it is, can other squads use it too? 3) Can we move bugs away from tripleo-docs when needed?
12:22:31 <jaosorior> What do you think?
12:23:05 <moguimar> sounds like a plan, but I still thing this is a bigger workarround that having our own repo
12:23:17 <mwhahaha> moguimar: well i don't want to create a repo for every squad
12:23:18 <jaosorior> moguimar: well, mwhahaha had some concerns on having a repo just for this. I assume mostly it's because of the overhead on having to maintain yet another repository.
12:23:30 <mwhahaha> because it's not just this squad
12:23:39 <mwhahaha> i'd rather either move everyone or not at all
12:23:47 * mwhahaha would like to not move at all but that's another story
12:24:28 <moguimar> then can you create a temp repo for every squad?
12:24:37 <moguimar> like tripleo-repositoryless
12:24:50 <mwhahaha> i don't know how that's different than tripleo-docs
12:25:00 <moguimar> so we don't invade tripleo-docs with non tripleo-docs related stuff?
12:25:06 <mwhahaha> because we won't be importating anything into tripleo-docs
12:25:14 <mwhahaha> we don't have any bug classification for tripleo-docs bugs
12:25:26 <mwhahaha> so we won't actually import anything associated with tripleo-docs
12:25:32 <moguimar> got it
12:26:09 <moguimar> let's try it then :)
12:26:30 <jaosorior> moguimar, mwhahaha: Is the tripleo-docs solution a viable path in your opinion then? (after answering the questions I posted above)
12:26:39 <moguimar> yep
12:26:44 <mwhahaha> yea
12:26:47 <jaosorior> Alright
12:27:16 <jaosorior> #action moguimar and jaosorior to answer the following before proceeding with storyboard: 1) Is using tripleo-docs an option? 2) if it is, can other squads use it too? 3) Can we move bugs away from tripleo-docs when needed?
12:27:32 <jaosorior> mwhahaha: thanks for joining in as well
12:27:52 <mwhahaha> gotta be up at 6am anyway ಠ_ಠ
12:27:58 <jaosorior> Anything else folks want to bring up about this topic?
12:28:01 <jaosorior> mwhahaha: ouch
12:28:30 <raildo> nothing from my side
12:28:41 <moguimar> me neither
12:28:55 <jaosorior> #topic Secret Management Work update
12:29:25 <jaosorior> So, the good news is that for securing the overcloud plan (which is stored in swift); the proposed solution is quite straight forward
12:29:49 <jaosorior> Swift already supports object encryption (at rest)
12:29:55 <jaosorior> and that's already implemented in the overcloud
12:30:23 <jaosorior> So, with a few patches alee and me managed to get object encryption for the undercloud as well
12:30:37 <jaosorior> note that this work only applies for the containerized undercloud
12:31:01 <raildo> jaosorior, that's a great work, congrats dude!
12:31:02 <jaosorior> But if you would like to check it out, here are all the patches https://review.openstack.org/#/q/topic:secret-management+(status:open+OR+status:merged)
12:31:39 <jaosorior> Now, currently it's disabled by default; and I only proposed to enable it in one job (undercloud-containers or fs027)
12:32:09 <jaosorior> However, I think that enabling it by default would not be too problematic (except for the basic undercloud taking more resources than before)
12:32:27 <jaosorior> So, I'm planning to propose that in the mailing list
12:32:49 <alee> +1
12:33:06 <jaosorior> Now, it would take more resources because in order to get object encryption, Barbican needs to be deployed, since that's currently the only viable solution we can support
12:33:19 <jaosorior> however, in the future, we could exchange Barbican for Vault or something else.
12:33:28 <raildo> jaosorior, I suggest get that result for this job showing that the feature is working well, for like 1 month, so you can have some argument that "we're not breaking anyone"
12:33:28 <jaosorior> Anyway, the current proposal is with Barbican.
12:33:41 <jaosorior> raildo: that's a good idea
12:33:50 <jaosorior> I dig it
12:34:02 <raildo> #link http://status.openstack.org/openstack-health/#/
12:34:11 <openstackgerrit> Brad P. Crochet proposed openstack/tripleo-validations master: Add validation for checking baremetal boot images  https://review.openstack.org/555325
12:34:12 <raildo> usually you can get this stuff on this link
12:34:13 <jaosorior> So, the mail will be sent in a month, and lets see what the rest of the community thinks
12:34:55 <jaosorior> Any questions/feedback?
12:35:22 <alee> jaosorior, I'm not sure we need to wait a month to send out the email and get feedback
12:35:33 <chem> owalsh: hey, so you've seen, one can get the actual set values for the the host parameter in a fact ...
12:35:50 <jaosorior> alee: could be a couple of weeks after this merges
12:36:02 <raildo> alee, ++ it was just an idea, that you can add this info later in the thread :)
12:36:07 <chem> owalsh: but for one i think this would have never merged :) but the logic was getting complicated
12:36:13 <jaosorior> but I do agre with raildo that we should let the test run this for a while before proposing it as a default.
12:36:18 <chem> owalsh: s/but/and/
12:36:44 <openstackgerrit> Christian Schulze-Wiehenbrauk proposed openstack/puppet-pacemaker master: Fix missing pass-through of cluster_auth_enabled parameter  https://review.openstack.org/562263
12:36:54 <fultonj> sphinx-docs!
12:37:05 <alee> jaosorior, ok -- I'm ok with waiting for a little while - in the meantime lets see if there are other cases that are solved by having a barbican in the undercloud
12:37:06 <chem> owalsh: next review is about to make that host parameter immutable during upgrade/update/ffu so that we don't break ourself on purpose
12:37:34 <alee> or more specifically a castellan implementation
12:37:36 <jaosorior> alee: right, there's still a bunch of work to do
12:38:06 <jaosorior> but I think this is a pretty nice milestone for that work :)
12:38:17 <alee> agreed :)
12:38:20 <dpeacock> deployment from current is still b0rked - http://paste.openstack.org/show/719463/
12:39:04 <jaosorior> #topic Public TLS by default work update
12:39:15 <jaosorior> On a similar note
12:39:29 <jaosorior> most of the base work for getting TLS by default has been uploaded
12:39:45 <jaosorior> if you want to review what's there, or check out what was done
12:39:47 <jaosorior> here's the link
12:39:49 <jaosorior> #link https://review.openstack.org/#/q/topic:public-tls-default+(status:open+OR+status:merged)
12:40:25 <jaosorior> for this, jistr raised a very good point regarding that we should let folks with existing deployments keep having TLS off (if they initially deployed that way)
12:40:50 <jaosorior> So, the next part of that work is making sure updates leave the overcloud without TLS if that was the state it was in.
12:41:40 <jaosorior> Any questions/feedback?
12:41:49 <alee> jaosorior, is there a way to make that optional?
12:42:06 <jaosorior> alee: what do you mean?
12:42:26 <openstackgerrit> Giulio Fidente proposed openstack/tripleo-heat-templates stable/queens: DO-NOT-MERGE Test new ceph-container builds (OSP queens)  https://review.openstack.org/562215
12:42:42 <alee> jaosorior, that is -- I can see folks saying - boy, having tls would be great - maybe I can set something any have tls enabled for me
12:42:48 <openstackgerrit> Giulio Fidente proposed openstack/tripleo-heat-templates stable/pike: DO-NOT-MERGE Test new ceph-container builds (OSP pike)  https://review.openstack.org/562217
12:43:13 <openstackgerrit> Giulio Fidente proposed openstack/tripleo-heat-templates master: DO-NOT-MERGE Test new ceph-container builds  https://review.openstack.org/562213
12:43:15 <alee> jaosorior, or would that have to enable and then redeploy?
12:43:38 <tosky> jaosorior: stupid question: https://review.openstack.org/#/c/560430/ did not add CACert to scenario003 (which contains sahara) - is it because Sahara does not implement properly all the magic?
12:43:47 <tosky> (the thing that we discussed during the PTG)
12:43:56 <jaosorior> alee: well, currently there is no sure update/upgrade path
12:44:02 <jaosorior> tosky: I'll answer after the meeting
12:45:14 <jaosorior> alee: so, definitely something to consider when implementing the update/ugprade path. It should be possible for someone to say "Enable TLS if it's not there", with means of a simple flag or something of the sort
12:45:29 <alee> jaosorior, +1
12:45:29 <jaosorior> planning to sort out some of the details of that next week in Brno
12:45:40 <jaosorior> since a bunch of the folks that work in updates/upgrades will be there
12:45:51 <jaosorior> it's a great coincidence
12:47:18 <jaosorior> Anybody else has questions or would like to bring up something about this work?
12:47:28 <jaosorior> Also note that help is always welcome :D and there is still stuff to do on that side
12:48:22 <alee> I'm curious if there are any real deployments out there that dont have tls enabled on the public side ..
12:49:32 <jaosorior> alee: probably it's mostly labs and CI deployments. Not sure, to be honest.
12:49:43 <jaosorior> #topic Any other business
12:49:58 <jaosorior> Alright! That was all on my side. Anything anybody else wants to bring up to the meeting?
12:50:10 <lhinds> quick one from me, I have started shifting through sudoer use
12:50:11 <fungi> on the concern earlier about how to identify stories being handled by one squad or another even if they have tasks on the same repo(s), you can use story tags which are queryable
12:50:16 <lhinds> not much to update yet
12:50:24 <lhinds> #link ttps://etherpad.openstack.org/p/tripleo-heat-admin-security
12:51:09 <jaosorior> lhinds: well, that's a good start
12:51:21 <lhinds> just trying to get my head around what validations is doing
12:51:22 <jaosorior> lhinds: please reach out if you would like help and have ideas on how to divide that
12:51:32 <lhinds> jaosorior: ack, will do. thx
12:51:45 <jaosorior> lhinds: what do you need to know about validations?
12:52:16 <jaosorior> lhinds: maybe florianf, mandre or shadower can help you on that side.
12:52:24 <jaosorior> fungi: that's good to know!
12:52:31 <lhinds> It has its own account, and sudoers is ALL - so I need to find the instances of where it needs sudo.
12:52:43 <alee> lhinds, dont forget barbican
12:53:00 <jaosorior> alee: what do we use sudo for in barbican?
12:53:03 <alee> (both on the overcloud and undercloud)
12:53:25 <lhinds> alee: good point, does barbican have its own user account with a sudoers.d's file?
12:53:42 <lhinds> actually alee will ping you
12:53:56 <alee> sure -- jaosorior not sure offhand
12:53:57 <lhinds> we are almost at the end now, so I will discuss more indepth with you
12:54:31 <florianf> lhinds: It runs ansible playbooks and some of the tasks have the "become" attribute which tells ansible to run the tasks as root
12:54:39 <alee> lhinds, also novajoin user perhaps?
12:55:27 <lhinds> florianf: do you need "validations ALL = NOPASSWD: ALL" for that?
12:55:49 <lhinds> might not be a quick answer I understand, but for context, that is what we would like to limit more.
12:56:20 <openstackgerrit> Merged openstack/diskimage-builder master: Remove installed packages before pip install  https://review.openstack.org/561479
12:56:41 <lhinds> for example 'sudo su' or 'sudo rm / -fr --no-preserve-root'
12:58:18 <jaosorior> Alright
12:58:22 <florianf> lhinds: I guess I can't think of a good way to do this. This GH issue for ansible adds a bit of context: https://github.com/ansible/ansible/issues/5712
12:58:42 <lhinds> thanks florianf , will take a read
12:59:08 <jaosorior> seems we're out of time
12:59:12 <jaosorior> thanks everybody for joining!
12:59:20 <jaosorior> #endmeeting