15:00:48 <gagehugo> #startmeeting security
15:00:48 <openstack> Meeting started Thu Aug 29 15:00:48 2019 UTC and is due to finish in 60 minutes.  The chair is gagehugo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:51 <openstack> The meeting name has been set to 'security'
15:01:05 <gagehugo> #link https://etherpad.openstack.org/p/security-agenda agenda
15:01:12 <gagehugo> o/
15:01:21 <mhen> o/
15:01:22 <nickthetait> hi hi
15:01:28 <nickthetait> ahem
15:01:29 <nickthetait> o/
15:01:40 * fungi is half-here
15:03:45 <gagehugo> #topic OSSA-2019-004
15:03:57 <gagehugo> #link https://security.openstack.org/ossa/OSSA-2019-004.html
15:04:17 <gagehugo> Hot off the press
15:04:22 <gagehugo> thanks fungi for handling that
15:05:29 <fungi> no sweat
15:05:47 <fungi> the public workflow is a lot easier than dealing with embargoes ;)
15:06:06 <nickthetait> for sure!
15:06:49 <fungi> note that deliverable technically isn't vulnerability:managed
15:07:07 <fungi> but handling it was related to a wip governance change i've proposed
15:07:10 <fungi> Update vulnerability:managed policy
15:07:14 <fungi> er...
15:07:17 <fungi> note that deliverable technically isn't vulnerability:managed
15:07:25 <fungi> #link https://review.opendev.org/678426 Update vulnerability:managed policy
15:07:57 <fungi> clearly i'm not as thoroughly caffeinated as i should be
15:08:20 * nickthetait takes a sip of tea
15:08:38 <fungi> anyway, feedback is encouraged on that since it's a bit of a paradigm shift in how the openstack vmt has been operating for a number of years
15:09:10 <nickthetait> what is the change in process?
15:09:54 <fungi> it's more of a change in policy
15:10:08 <fungi> summary is: turn the risk assessment requirement into more of a recommendation, but also lower the number of embargoed bugs the vmt needs to track by setting a hard limit on how long a report can remain private
15:10:25 <nickthetait> ok that sounds sensible
15:10:44 <fungi> also clarifies that extended-maintenance branches are "best effort"
15:11:25 <fungi> and that the vmt doesn't track or publish advisories about software components which might be included in release artifacts but which are not themselves written by openstack
15:11:39 <fungi> (for example, vulnerable glibc in a kolla image)
15:13:24 <nickthetait> I'll commit to doing a full review of that today
15:16:21 <fungi> yeah, the only major changes are the risk assessment and the max embargo period, the rest are just clarifications
15:18:06 <gagehugo> cool
15:18:10 <gagehugo> #topic Open Discussion
15:18:25 <gagehugo> Floor is open if anyone has anything
15:18:29 <nickthetait> I have good news :D
15:18:37 * fungi braces for good news
15:18:53 <gagehugo> good news is always good
15:18:58 <nickthetait> https://docs.openstack.org/security-guide/ now says "last updated during Train"
15:19:07 <nickthetait> landed at like 5am today hehe
15:19:21 <nickthetait> a few other major changes were merged yesterday too
15:19:32 <gagehugo> yup, a lot of good cleanup has gone in
15:19:39 <gagehugo> thanks for doing all those nickthetait
15:19:58 <nickthetait> yep!
15:20:01 <nickthetait> two other minor ones waiting on reviews
15:20:48 <nickthetait> #link https://review.opendev.org/#/c/677494/
15:20:54 <nickthetait> #link https://review.opendev.org/#/c/677513/
15:22:14 <nickthetait> Also have a question about this
15:22:17 <nickthetait> #link https://bugs.launchpad.net/ossp-security-documentation/+bug/1703353
15:22:19 <openstack> Launchpad bug 1703353 in OpenStack Security Guide Documentation "Need sections on api audit / cadf" [High,Confirmed]
15:22:23 <nickthetait> is it still relevant/needed
15:22:33 <nickthetait> I'm not clear on what content it is asking for
15:22:44 <gagehugo> sure
15:23:01 <gagehugo> lemme find some links
15:23:54 <gagehugo> (as someone who's org uses cadf) I'd say sure it's relevant
15:25:11 <nickthetait> :)
15:25:24 <gagehugo> #link https://www.dmtf.org/standards/cadf
15:25:49 <gagehugo> there's some specs on CADF itself (only 183 pages)
15:26:33 <gagehugo> and the audit middleware is good too
15:26:37 <gagehugo> #link https://docs.openstack.org/keystonemiddleware/latest/audit.html
15:27:47 <gagehugo> and keystone has a page that dives into more details about the event notifications themselves
15:27:50 <gagehugo> #link https://docs.openstack.org/keystone/latest/admin/event_notifications.html
15:28:13 <gagehugo> nickthetait: have you configured event notifications for openstack before?
15:28:27 <nickthetait> i sure haven't
15:28:33 <gagehugo> I can help out with that one, I've done it for our cloud
15:28:56 <nickthetait> this would be a new page under the compliance chapter?
15:29:40 <gagehugo> either that, or monitoring and logging
15:29:53 <nickthetait> ok
15:30:52 <gagehugo> as CADF events are notifications from events in openstack (project create, user auth, server create, etc.)
15:31:18 <nickthetait> gotcha
15:31:32 <nickthetait> well thats it from me
15:32:17 <gagehugo> nickthetait: I'll see if I can throw something together for that
15:32:41 <gagehugo> imo it would be good to have a guide on how to do it, I had to wing it myself and I wish I had a clearer guide
15:33:15 <nickthetait> throw a comment on that bug and I'll work my magic and turn it into documentation
15:33:23 <gagehugo> will do
15:33:50 <gagehugo> #action: gagehugo to leave a comment on https://bugs.launchpad.net/ossp-security-documentation/+bug/1703353
15:33:50 <openstack> Launchpad bug 1703353 in OpenStack Security Guide Documentation "Need sections on api audit / cadf" [High,Confirmed]
15:34:42 <gagehugo> anything else?
15:34:44 <mhen> I've got another small topic I'd want to address
15:35:00 <mhen> sorry, I haven't been able to attend the last two meetings
15:35:16 <gagehugo> mhen: sure!
15:35:28 <gagehugo> the last couple meetings were fairly non-existant so no worries
15:35:33 <mhen> but I started a discussion before about Cinder suddenly deciding to change the policy format standard
15:35:41 <mhen> was there any update on that so far?
15:35:54 <gagehugo> mhen: I still have a sticky note on my monitor to dig into that
15:36:00 <gagehugo> no update yet, sorry
15:36:05 <mhen> no problem
15:36:08 <gagehugo> it's on my todo list though :)
15:36:20 <mhen> today I happened to notice that Cinder still used .json in Pike
15:36:24 <mhen> but changed it in Queens
15:36:31 <mhen> and so far it still seems to be the only one
15:36:37 <gagehugo> hmm ok
15:36:44 <nickthetait> what format is it changing to?
15:36:48 <mhen> .yaml
15:36:51 <nickthetait> ah
15:36:59 <mhen> it overrides oslo_policy's default
15:37:13 <mhen> which no  other OpenStack service does currently afaik
15:37:32 <mhen> so, any expectation about services behaving consistently is now broken
15:37:36 <gagehugo> There was an effort to move all policy files to yaml (for comment support), but it seems that multiple projects are inconsistent about describing that they support
15:37:50 <nickthetait> ugh messy
15:38:04 <mhen> biggest problem is, services ignore any format that is not the default
15:38:16 <mhen> *their defaut ;)
15:38:23 <mhen> *default
15:38:24 <mhen> jeez
15:38:27 <mhen> :D
15:38:29 <nickthetait> hehe
15:39:40 <mhen> had this again today, an infrastructure upgraded from Pike to Queens and then things started to break because the policy file for Cinder (previously working .json) was now ignored
15:41:18 <fungi> any idea if that has improved since queens?
15:41:31 <fungi> we've had two more releases since then and are about to have another
15:41:44 <mhen> last time I checked (2 weeks ago), the master branch still had the same overriding code in Cinder
15:42:19 <mhen> #link https://github.com/openstack/cinder/blob/master/cinder/policy.py#L31
15:42:49 <mhen> compare to
15:42:51 <mhen> #link https://github.com/openstack/cinder/blob/stable/pike/cinder/policy.py#L26
15:43:26 <gagehugo> It looks like it's an issue when upgrading and there not being clear direction that your policies will suddenly start getting ignored because they're not the correct file format, when it worked fine previous release
15:43:39 <mhen> exactly
15:43:52 <gagehugo> and some services work, and others don't
15:44:19 <smcginnis> It could have been better, but that was documented in the upgrade notes: https://docs.openstack.org/releasenotes/cinder/queens.html#upgrade-notes
15:44:38 * fungi wonders if folks don't read upgrade notes when upgrading
15:44:57 <smcginnis> Usually not. ;)
15:46:14 <gagehugo> "The sample file is YAML (because unlike JSON, YAML allows comments). If you prefer, you may use a JSON policy file."
15:46:24 <gagehugo> I assume you need to specify your policy file though
15:46:39 <smcginnis> "The policy file to be used may be specified in the /etc/cinder/cinder.conf"
15:46:52 <nickthetait> well thats annoying but not unfixable for an operator
15:46:55 <mhen> if you wanna use .json, you have to set 'policy_file' in the config starting with Queens
15:48:20 <fungi> ahh, so it does continue to support json, you just need to add a config line
15:48:30 <mhen> yes
15:48:34 <fungi> and i guess the upgrade notes weren't clear enough on that point
15:48:42 <nickthetait> so the line smcginnis quoted should really say "starting with Queens if you want to use .json, you must set 'policy_file' in /etc/cinder/cinder.conf"?
15:49:11 <smcginnis> Well, .json or whatever other file you want to use other than the default.
15:50:03 <nickthetait> "Starting with Queens .yaml is the default format. If you want to use any other format you must set 'policy_file' in /etc/cinder/cinder.conf"
15:51:02 <gagehugo> I assume the nova issue you saw mhen might be similar
15:51:35 <mhen> yes, it's imply vice versa, defaulting to .json - ignoring .yaml
15:51:43 <mhen> I just mentioned it as a comparison
15:52:01 <mhen> so that you can't use a single consistent format if relying on defaults across the components
15:52:19 <mhen> I agree that it wasn't entirely undocumented and is an avoidable problem. However, I see this more as a general issue considering that OpenStack components should have consistent and sensible defaults across the board when it comes to security critical configuration, in my opinion.
15:52:54 <mhen> especially, since from my experience the documentation about which format to choose for which component is very scattered and even misleading at times
15:53:01 <gagehugo> So a good path forward would be to improve the documentation then, that's something we can do.
15:54:17 <gagehugo> mhen: nickthetait is already helping us with our misleading documentation :)
15:54:29 <gagehugo> (and quite outdated)
15:54:38 * nickthetait strongly agrees with mhen
15:54:46 <mhen> from a security point of view, I don't fully understand how Cinder is allowed to go it's own way so light-minded
15:54:58 <nickthetait> is there anything we can do outside docs?
15:55:22 <mhen> convince Cinder to stay in line again ;)
15:55:33 <nickthetait> the complexity does impact the security of a deployment
15:56:08 <nickthetait> harder to maintain your current stance through an upgrade
15:56:49 <fungi> did cinder "go its own way" or did the rest of the services simply not get around to implementing the new interface yet?
15:57:14 <fungi> but i do agree that a coordinated transition for something like this across most projects would have been nicer for deployers
15:57:41 <gagehugo> I think there's inconsistencies, if nova is indeed defaulting to json still
15:57:51 <smcginnis> Cinder followed what the community release goal was to implement policy in code. Part of that was using oslo_policy which sets the default. (IIRC)
15:58:01 <mhen> gagehugo, every service but Cinder does afaik
15:58:20 <gagehugo> I thought keystone does yaml now
15:58:26 * gagehugo digs though release notes
15:58:42 <gagehugo> mhen: or do you mean in the Queens release?
15:58:58 <mhen> but Cinder forcibly overrides the oslo_policy default, https://github.com/openstack/cinder/blob/master/cinder/policy.py#L31
15:59:37 <smcginnis> Ah, that was an oversight then. So is it worse to be different now or to make people change yet again?
15:59:42 <mhen> I work with Queens on a daily basis, so yeah - I didn't check all current master branches
16:00:58 <gagehugo> we're out of time, we can continue this in #openstack-security, thanks for coming everyone
16:01:03 <nickthetait> later
16:01:14 <gagehugo> #endmeeting