12:00:15 <jaosorior> #startmeeting TripleO Security Squad
12:00:16 <openstack> Meeting started Wed May  9 12:00:15 2018 UTC and is due to finish in 60 minutes.  The chair is jaosorior. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:19 <openstack> The meeting name has been set to 'tripleo_security_squad'
12:00:26 <jaosorior> Hello folks!
12:00:32 <jaosorior> will wait some minutes for more folks to log in
12:01:04 <moguimar> #link https://etherpad.openstack.org/p/tripleo-security-squad
12:01:57 <jaosorior> thanks moguimar
12:01:58 <raildo> o/
12:01:59 <openstackgerrit> Juan Antonio Osorio Robles proposed openstack/tripleo-quickstart master: Add overcloud-prep-config to the default tags  https://review.openstack.org/567202
12:02:06 <moguimar> o/
12:02:53 <jaosorior> lhinds, alee__, hrybacki around?
12:04:22 <moguimar> owalsh d0ugal
12:04:45 <jaosorior> #topic Public TLS work update
12:05:12 <jaosorior> #link https://review.openstack.org/#/q/topic:public-tls-default+(status:open+OR+status:merged)
12:05:20 <jaosorior> The patches are mentioned in the link I posted above
12:05:43 <jaosorior> And pretty much everything TLS related has been posted as a patch.
12:05:56 <jaosorior> There are two things to do though
12:06:00 <jaosorior> first, documentation.
12:06:26 <jaosorior> I need to write the appropriate documentation on what folks should expect and do now that we have TLS by default in the public interfaces of both the undercloud and the overcloud (well... not now, but once it merges)
12:06:35 <jaosorior> second
12:06:50 <jaosorior> there was a bug that was uncovered while working on tls by default for the overcloud
12:07:04 <jaosorior> even though it's not directly a TLS issue, I would like to get that fixed
12:07:32 <jaosorior> and it's the fact that bootstrap roles from docker_puppet_tasks only get ran the bootstrap (primary) node
12:08:01 <jaosorior> this means that if keystone is not in the primary node, TripleO won't generate the needed endpoints and users
12:08:08 <jaosorior> why was this uncovered with TLS?
12:08:22 <jaosorior> because HAProxy will only get the certificates if it's in the primary or controller node
12:08:29 <jaosorior> so, tags matter
12:09:01 <raildo> jaosorior, do you have a link for this bug?
12:09:23 <jaosorior> raildo: https://launchpad.net/bugs/1767972
12:09:26 <openstack> Launchpad bug 1767972 in tripleo "docker_puppet_tasks won't run unless service is in primary node" [High,In progress] - Assigned to Juan Antonio Osorio Robles (juan-osorio-robles)
12:09:33 <raildo> thanks
12:09:49 <jaosorior> I had a potential fix... but upon further discussion with shardy, that's not the approach we want to take.
12:09:56 <jaosorior> in the end, we want to have bootstrap nodes per-service
12:10:15 <jaosorior> and not a global bootstrap node
12:10:22 <jaosorior> which is what we have at the moment.
12:10:37 <raildo> yeah, makes sense
12:10:50 <jaosorior> anyway, just stuff that blocked the TLS work for a bit.
12:11:03 <jaosorior> that's all on my side for the public TLS by default work
12:11:07 <jaosorior> Any questions/feedback?
12:11:12 <openstackgerrit> Jiri Tomasek proposed openstack/tripleo-ui master: Exclude nodes deployed with another deployment plan  https://review.openstack.org/563646
12:11:12 <openstackgerrit> Jiri Tomasek proposed openstack/tripleo-ui master: Add sanitizeMessage function  https://review.openstack.org/564502
12:11:13 <openstackgerrit> Jiri Tomasek proposed openstack/tripleo-ui master: Add deployment status tracking infrastructure  https://review.openstack.org/559021
12:11:13 <openstackgerrit> Jiri Tomasek proposed openstack/tripleo-ui master: Enable config-download deployment tracking  https://review.openstack.org/559022
12:11:14 <openstackgerrit> Jiri Tomasek proposed openstack/tripleo-ui master: Chain ansible messages in deployment progress  https://review.openstack.org/564733
12:11:14 <openstackgerrit> Jiri Tomasek proposed openstack/tripleo-ui master: [WIP] Call undeploy_plan workflow to delete deployment  https://review.openstack.org/566366
12:11:36 <raildo> nope
12:12:01 <jaosorior> #topic Secret management
12:12:32 <jaosorior> So, enabling the containerized undercloud to use swift object encryption to store the plan merged some weeks ago
12:12:48 <jaosorior> now that it's been tested in CI for a bit. I would like to propose it as the new default
12:13:01 <jaosorior> This, with the reasoning that the configuration is fairly un-noticeable by the user
12:13:20 <jaosorior> old objects remain unencrypted (and still usable), and new objects will be encrypted
12:13:22 <jaosorior> which is great
12:13:42 <jaosorior> so, I proposed a patch today to make it the new default https://review.openstack.org/567200
12:13:56 <jaosorior> and I'll send a mail tot he mailing list to get more visibility to this
12:14:26 <jaosorior> so... yay for secure defaults :D
12:14:35 <raildo> jaosorior, sounds awesome!
12:15:08 <moguimar> do we have a plan to later migrate the unencrypted objects?
12:15:40 <jaosorior> moguimar: currently there's no way to do that; other than deleting the unencrypted objects and uploading them again.
12:16:05 <jaosorior> moguimar: this is not too problematic for folks that use the CLI, since that's what happens by default anyway. but for folks using the UI, they would need to delete their plan and upload it again.
12:16:18 <openstackgerrit> Carlos Goncalves proposed openstack/tripleo-common master: Fix syntax error in octavia-undercloud role  https://review.openstack.org/567205
12:16:35 <jaosorior> now, this is not a requirement for everybody, so, I doubt a lot of folks will care if their plan is unencrypted at rest.
12:17:59 <jaosorior> moguimar: though, of course, having a migration strategy would be ideal. Gotta poke the Swift folks to see if they have any ideas.
12:19:22 <openstackgerrit> Jiri Tomasek proposed openstack/tripleo-ui master: Integrate redux-devtools Chrome extension  https://review.openstack.org/567208
12:19:56 <jaosorior> #topic SELinux: Lets start following our audit logs
12:20:04 <openstackgerrit> Jiri Tomasek proposed openstack/tripleo-ui master: Enable config-download deployment tracking  https://review.openstack.org/559022
12:20:04 <openstackgerrit> Jiri Tomasek proposed openstack/tripleo-ui master: Chain ansible messages in deployment progress  https://review.openstack.org/564733
12:20:05 <openstackgerrit> Jiri Tomasek proposed openstack/tripleo-ui master: [WIP] Call undeploy_plan workflow to delete deployment  https://review.openstack.org/566366
12:20:11 <jaosorior> This one is regarding the SELinux everywhere work
12:20:26 <jaosorior> talking to folks, the idea came up for a start in this work
12:20:39 <jaosorior> right now we are collecting the audit logs from the CI jobs, but we're not doing anything with them
12:21:23 <jaosorior> now, I'm not sure if we plain disable SELinux or we set it to permissive
12:21:47 <jaosorior> but, lets have SELinux as permissive, monitor errors in the audit logs, and start being more proactive in reporting such issues.
12:22:00 <jaosorior> If folks have ideas on how to go forward with that, they would be appreciated.
12:22:28 <jaosorior> Let me start an etherpad for that.
12:22:45 <jaosorior> here you go
12:22:47 <jaosorior> #link https://etherpad.openstack.org/p/tripleo-selinux-everywhere
12:24:10 <jaosorior> Now, the tricky part is that openstack-selinux (the package where we have the selinux rules for openstack services) is handled in a way that RHEL gets the updated package first, and then CentOS
12:24:14 <jaosorior> even though it's part of RDO
12:24:21 <jaosorior> so, this might be a little complicated
12:24:40 <jaosorior> but at least being on top of any new denials and reporting them proactively, would be a nice step forward.
12:25:29 <openstackgerrit> Brad P. Crochet proposed openstack/tripleo-common stable/queens: Add a 'trash_output' flag to ansible playbook action  https://review.openstack.org/566884
12:25:44 <jaosorior> Anyway, ideas are welcome on that front
12:26:24 <raildo> jaosorior, let's define some next steps on that, sounds like we are at the beginning on this topic, so we might need some more details to get some decisions on that
12:26:46 <openstackgerrit> Saravanan KR proposed openstack/tripleo-heat-templates master: NFV: Support for config-download to deploy node with kernel args  https://review.openstack.org/560767
12:26:47 <openstackgerrit> Saravanan KR proposed openstack/tripleo-heat-templates master: DO NOT MERGE: Test boot params in the config-download  https://review.openstack.org/566241
12:26:47 <raildo> I mean, add those next steps that you're talking about in the etherpad and see what we can do :)]
12:27:01 <jaosorior> sure, I'll do that
12:28:23 <jaosorior> Any more questions/feedback?
12:29:52 <jaosorior> #topic Any other business
12:30:10 <jaosorior> Anything else someone wants to bring up to the meeting?
12:30:24 <raildo> nothing from me
12:30:25 <moguimar> not on my end
12:30:31 <jaosorior> Alright! thanks for joining!
12:30:34 <jaosorior> #endmeeting