15:00:12 <gagehugo> #startmeeting security
15:00:15 <openstack> Meeting started Thu Aug  1 15:00:12 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:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:18 <openstack> The meeting name has been set to 'security'
15:00:30 <gagehugo> #link https://etherpad.openstack.org/p/security-agenda
15:00:55 <gagehugo> o/
15:00:58 <nickthetait> hi
15:01:03 <mhen> o/
15:01:44 <gagehugo> we will start in a couple minutes
15:03:41 <gagehugo> ok
15:03:44 <gagehugo> #topic Security Bug
15:04:12 <gagehugo> #link https://bugs.launchpad.net/os-vif/+bug/1837252
15:04:14 <openstack> Launchpad bug 1837252 in os-vif trunk "IFLA_BR_AGEING_TIME of 0 causes flooding across bridges" [High,In progress] - Assigned to sean mooney (sean-k-mooney)
15:04:55 <gagehugo> if anyone can take a look at ^, it would be appreciated
15:05:18 <gagehugo> it looks a bit similar to other bugs, but there's comments stating that its affecting multiple network backends
15:05:48 <gagehugo> #topic Security Guide Updates
15:05:49 <fungi> hey, sorry, our broadband provider seems to have lost contact with the mainland at 15:00z precisely (i'm back on through a wireless modem for now)
15:06:00 <gagehugo> fungi: oh no
15:06:12 <fungi> it happens with some regularity
15:06:30 <fungi> i need to get around to hooking a wireless modem directly to my home firewall as a backup connection
15:06:57 <gagehugo> nickthetait: I asked cmurphy about the federation guide, it's quite out of date and it would probably be best to just link directly to the keystone federation guide
15:07:07 <gagehugo> #link https://docs.openstack.org/keystone/latest/admin/federation/introduction.html
15:07:22 <nickthetait> ok good deal
15:07:46 <gagehugo> also, one less page for us to keep up-to-date
15:08:21 <nickthetait> exactly
15:08:46 <gagehugo> nickthetait: any other issues currently?
15:08:53 <gagehugo> I saw a bunch of changes got merged
15:09:12 <nickthetait> no issues and yes first changes have landed :)
15:09:20 <gagehugo> \o/
15:09:25 <nickthetait> one question about checklists
15:09:31 <gagehugo> sure
15:09:35 <nickthetait> for example https://docs.openstack.org/security-guide/identity/checklist.html
15:09:46 <nickthetait> how can I verify these are relevant and still useful?
15:12:05 <gagehugo> you would need to be aware of the current state of that project haha
15:12:14 <gagehugo> 04 is not relevent
15:12:20 <gagehugo> PKI tokens are gone
15:12:36 <gagehugo> I think 05 can be changed
15:13:04 <gagehugo> I would need to check the value off the top of my head
15:13:11 <gagehugo> I can't remember*
15:13:53 <gagehugo> nickthetait: I'll look through those and let you know
15:13:56 <nickthetait> hmm so there will be some serious work to get those sorted out
15:14:00 <nickthetait> thx
15:14:09 <gagehugo> #action gagehugo to look through https://docs.openstack.org/security-guide/identity/checklist.html
15:14:22 <gagehugo> the other services likely will need updates as well
15:14:30 <nickthetait> yes for sure
15:15:15 <gagehugo> #topic Cinder/Nova Policy Follow-Up
15:15:39 <gagehugo> mhen: o/
15:15:44 <mhen> hi :)
15:16:19 <gagehugo> I looked at this briefly, and I saw you commented on that nova ps
15:16:40 <mhen> sorry but I had to give a -1 for now on the ps
15:16:48 <gagehugo> oh no worries
15:16:51 <mhen> I think the proposed documentation change is tackling the problem from the wrong side to be honest
15:16:59 <gagehugo> it probably is :)
15:18:24 <mhen> we could introduce clear statements of all the different cases where either yaml or json is required/expected in the docs
15:18:40 <mhen> but the root problem imo is still that Nova behaves differently than Cinder
15:18:57 <gagehugo> yeah, each service tends to do that
15:19:36 <gagehugo> I agree though, we can addon to that ps to tackle all of the cases
15:20:16 <gagehugo> I think your comment also clarified more of the issue for me as well
15:20:42 <mhen> by the way, the change required to make one of the services adapt to the other's default in regards to policy format is one line of code only for either
15:20:43 <gagehugo> but I also have been heads-down the last week, so haven't had much time to look deeper into it, but it's calmed down a bit here
15:21:01 <gagehugo> yeah, more to bring them in sync
15:21:20 <mhen> gagehugo, no problem. I hope my comment can help understanding the problem.
15:23:04 <mhen> wouldn't the default policy format (as a security related decision) important to be consistent across OpenStack?
15:23:34 <gagehugo> oh yes
15:24:05 <gagehugo> there's been other policy related groups at various summits as well, so it's not only a "security" topic
15:25:31 <fungi> unified policy management has been a long time need opwnstack-wise
15:25:39 <fungi> er, openstack-wide
15:25:59 <gagehugo> yes
15:26:46 <gagehugo> #action: follow up on nova ps, check cinder's docs/policy generation, attempt to unify them
15:27:02 <mhen> is anybody aware of other component's default format? (aside from Nova and Cinder) I haven't looked into others yet ...
15:27:51 <gagehugo> keystone's sample is json iirc
15:28:19 <gagehugo> but it generates a yaml if you genpolicy
15:28:42 <mhen> the sample might be misleading btw, it's important what the service is actually trying to parse during startup when no config option is set
15:31:17 <gagehugo> well, services also have policy-in-code as well
15:31:17 <mhen> anyway, if it turns out either Nova or Cinder is the only one using a different default across OpenStack, we could possibly convince them to change it, no?
15:31:48 <gagehugo> If we have a clear directive to get the services to follow the same format, it should be fine
15:31:55 <fungi> i think so, yes. though that may require time if it means behavior changes for folks at upgrade
15:32:07 <gagehugo> that is true
15:32:48 <fungi> in the past we've taken tactics like deprecating the old options and introducing new options which default to the new value but you have to remove the old option for them to take effect
15:32:50 <fungi> stuff like that
15:33:38 <fungi> so that on upgrade the behavior doesn't change, but the defaults do either when you remove the old option or pass the end of the deprecation period when the service no longer recognizes the old option at all
15:34:06 <mhen> non-trivial, I see
15:35:10 <mhen> another option would be to convince Cinder to try looking up a json if yaml isn't found (in case the assumption that Cinder is the only one using yaml per default currently, holds true)
15:36:54 <gagehugo> mhen: so if you specify "policy.yaml" in the config, but you have json, it will look for either?
15:37:59 <mhen> gagehugo, that might actually be a bit problematic. I'd suggest only looking for json as well if 'policy_file' is not explicitly set at all in Cinder
15:38:17 <gagehugo> I believe if you don't specify a file most services use the default in-code policy
15:39:12 <mhen> from my experience, they will also load whatever is their default format if available
15:39:41 <mhen> so, if you place a '/etc/nova/policy.json' it will be loaded if existing even if the config entry isn't specified
15:39:49 <gagehugo> I know that the services all don't work the same, so that could very well be the case
15:39:56 <gagehugo> for some, but not others
15:41:19 <mhen> from a quick browse through the code, it seems both Glance and Keystone also use the oslo.config default setting which is json, which hints at Cinder possibly being the only one loading yaml per default
15:42:00 <mhen> gagehugo, you mean there are services which will not load any policy file at all unless specified in their config as 'policy_file = <path>'?
15:43:16 <gagehugo> mhen: I am not 100% sure, they're all different
15:43:40 <gagehugo> this was one of the pain-points about the policy-in-code movement iirc
15:44:10 <mhen> if that is true, the whole inconsistency situation is a lot worse than I thought :D
15:44:32 <gagehugo> I mean, we explicitly deploy with a custom policy file that we specify in each service's config
15:44:55 <gagehugo> what each service does for "default" behavior though, that's a good quesiton
15:45:00 <gagehugo> question*
15:45:17 <mhen> it's always better to define everything explicitly but sadly not everyone does that
15:45:27 <fungi> yeah, the desire with policy-in-code, if i understand correctly, is that shipping policy as configuration meant a lot of boilerplate users had to manage, so instead it should be possible to get a working deployment with no explicit policy configuration at all (relying on the implicit default policies provided by the services)
15:45:52 <mhen> having sane defaults helps a lot imo
15:46:27 <fungi> well, as does documenting what the explicit equivalent of the implicit defaults looks like
15:46:48 <mhen> sure
15:47:42 <gagehugo> fungi: yes
15:52:13 <gagehugo> mhen: so I guess the path forward is to just keep this topic going, and follow up on nova/cinder for now
15:52:58 <mhen> gagehugo, agreed
15:53:32 <gagehugo> ok cool
15:53:36 <gagehugo> #topic open discussion
15:53:49 <gagehugo> 7 minutes left, anyone have anything else?
15:53:59 <nickthetait> i do
15:54:02 <nickthetait> https://docs.openstack.org/security-guide/identity/tokens.html
15:54:13 <nickthetait> fernet tokens have been the default for a while now
15:54:23 <nickthetait> ok to delete any non-fernet stuff on that page?
15:54:35 <gagehugo> uh
15:54:46 <gagehugo> yes, but also add JWT tokens
15:54:53 <nickthetait> will do
15:54:57 <gagehugo> lemme grab a link here real quick
15:55:25 <gagehugo> https://docs.openstack.org/keystone/stein/admin/tokens-overview.html#token-providers
15:55:46 <gagehugo> (we could just link to ^ as well)
15:55:53 <nickthetait> ok
15:56:04 <gagehugo> otherwise update the page with info from ^
15:56:33 <gagehugo> if we are discussing tokens from a security perspective, rather than a deployment one
15:56:45 <nickthetait> yes exactly :)
15:57:09 <gagehugo> ok
15:57:56 <gagehugo> thanks everyone, have a good rest of the week + weekend
15:57:59 <gagehugo> #endmeeting