16:00:08 <defionscode> #startmeeting Lockdown Working Group
16:00:08 <zodbot> Meeting started Thu Feb  7 16:00:08 2019 UTC.
16:00:08 <zodbot> This meeting is logged and archived in a public location.
16:00:08 <zodbot> The chair is defionscode. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:08 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:08 <zodbot> The meeting name has been set to 'lockdown_working_group'
16:00:24 <defionscode> @shepdelacreme might be late or absent today
16:00:49 <dericcrago> hi
16:01:24 <defionscode> Smallish update on my end, in my 'day job' im building out a product that will later have some utility for lockdown stuff and i'll be able to invest more time at that point, for now my contribution ability is limited to reviewing and maybe minor updates/fixes
16:02:18 <defionscode> mnaser are you on by chance? Im not sure if there has been any movement on getting access to openstack infra? cc/  odyssey4me
16:02:43 <mnaser> hi defionscode
16:02:57 <mnaser> sorry, i was flying around all over the place the past few weeks
16:03:01 <mnaser> (literally)
16:03:38 <mnaser> defionscode: so i assume you want to continue to maintain it in gerrit?
16:04:05 <defionscode> so as you know we've sort of ad-hoc been working on merging our projects
16:04:28 <defionscode> one of the points of agreement was that ya'lls testing infra was better
16:04:45 <defionscode> in terms of breadth of systems tested,e tc
16:05:09 <defionscode> not sure if it got the point of particular technical components (ie gerrit(
16:05:56 <mnaser> defionscode: if we move it over openstack infra, it's very easy to get it imported and get going with that
16:06:20 <defionscode> so that's the desire
16:06:47 <defionscode> on our end we're adding an extra task file that will allow the continued support of the other systems your folks currently support with ansible hardening
16:07:26 <odyssey4me> apologies, I've been stuck in all kinds of work for a while
16:07:31 <cyberpear> gerrit is the code review tool, right?  Is it completely separate from where the git repo is hosted?
16:07:36 <defionscode> and then the other decision point was to continue supporting ubuntu as-is or to go ahead and make content that follows the letter of the guidance of the Ubuntu-specific stig
16:07:46 <defionscode> odyssey4me same here
16:07:54 <odyssey4me> mnaser the plan was to allow ansible-lockdown to use zuul testing (via github pull requests) much like ansible does for the openstack modules
16:08:16 <odyssey4me> so it's not to import the repositories into gerrit - just consume zuul for testing
16:08:21 <mnaser> odyssey4me: i see, we can bring that up to the infra team, if someoen can maybe send out an email to `openstack-infra@lists.openstack.org` should probably be a good thing
16:08:59 <odyssey4me> well, let me take the conversation to them right now and see if we can get a how-to back
16:09:04 <odyssey4me> I suspect it's documented somewhere
16:09:29 <defionscode> ok, well if I need to send an email or anything i can do it, just lmk odyssey4me
16:11:01 * cyberpear wonders what the next steps are for the merge
16:11:11 <defionscode> mnaser so the other thing we wanted to your input on was what i mentioned a moment ago, ubuntu as-is or break it out into it's own role since it has it's own STIG now
16:11:47 <defionscode> So i'll have to check but I think @shepdelacreme has either finished or is nearly finished with setting up our docs to align well with AH docs
16:12:03 <defionscode> the thing that is left was to see how we could do nested docs
16:12:17 <mnaser> defionscode: i think ideally i feel like we should have one role that runs the right stig™
16:12:23 <defionscode> as in one main docs site for "Ansible Lockdown" that could then feed into sub projects by role
16:13:04 <defionscode> mnaser so the problem there is that is far too much given that lockdown aims to "one day" have roles for many many STIG and CIS benchmarks
16:13:09 <odyssey4me> well, the parent doesn't necessarily have to be a role - it could be playbooks that use the right role
16:13:14 <defionscode> to have it all in one role is a non starter b/c of that
16:13:17 <defionscode> correct
16:13:33 <mnaser> so it sounds to me that the answer is we have to split them :)
16:13:34 <defionscode> it should be the playbook that determines what role to use
16:13:50 <odyssey4me> that would be the most efficient, I think
16:13:56 <defionscode> well ubuntu has a chance to be a light exception given that you currently support it with AH
16:14:03 <odyssey4me> (in terms of execution)
16:14:10 <defionscode> i agree
16:14:22 <odyssey4me> there's nothing worse that waiting for thousands of lines of skips when you have a few hundred servers
16:14:25 <defionscode> i just wanted to provide minimal friction to the project merger
16:14:52 <defionscode> but ok, so splitting ubuntu into it's own role, cool, any objections?
16:14:57 <cyberpear> I could imagine a super-role, for OS-level benchmarks, but likely each product benchmark would have to be it's own role
16:15:00 <odyssey4me> sgtm
16:15:05 <cyberpear> (postgres or apache, for example)
16:15:35 <shepdelacreme> There are also some various issues with having multiple roles under a parent playbook because of the non-namespacing of handlers and what not
16:15:40 <cyberpear> yep
16:16:05 <cyberpear> or specifically in the same play.  Same playbook, different plays is okay
16:16:18 <odyssey4me> sure, but that's easily sorted out by ensuring that everything is namespaced with a role prefix
16:16:20 <shepdelacreme> right
16:17:04 <defionscode> so just to be explicit, it sounds like no objection from mnaser on splitting ubuntu? then with that we can say that ubuntu and docs merger are the things holding up finalization of the merger, unless i missed something?
16:17:22 <defionscode> oh and testing infra access of course
16:17:28 <mnaser> i think im not opposed to it
16:18:00 <defionscode> #agreed ubuntu to have it's own role that aligns with the official stig for ubuntu
16:18:08 <shepdelacreme> the docs are basically done
16:18:15 <defionscode> i thought so
16:18:28 <defionscode> the bit that isnt afaik is the docs of docs
16:18:29 <shepdelacreme> https://rhel7-stig.readthedocs.io/en/latest/
16:18:46 <shepdelacreme> that is simple
16:19:07 <shepdelacreme> just a docs site in the Ansible Lockdown repo that points to all the sub role docs
16:19:12 <odyssey4me> with regards to the testing on openstack infra - IIRC this was only needed for platforms which AH currently covers, but AL does not?
16:19:26 <odyssey4me> eg: gentoo, fedora, etc
16:20:00 <defionscode> at a minimum yes
16:20:21 <defionscode> preferrably we can keep testing all in one place, iirc ya'll are already using molecule, no?
16:20:50 <shepdelacreme> we'd probably prefer to move away from testing RHEL and Cent in an AWS account to the openstack infra
16:21:04 <defionscode> but if the happy compromise is that w continue to test rhel/centos/docker as-is AND we have additional tests with your infra that's fine too
16:21:57 <defionscode> #idea have docs for each role linked from the lockdown root repo (and landing page)
16:22:02 <mnaser> i think we should be able to get more info about openstack-infra once we get the email
16:22:37 <defionscode> odyssey4me shall we send the email? or are you still going to hit them up directly?
16:23:14 <odyssey4me> I'm having a chat in #openstack-infra right now. It seems that they're being conservative with allowing this sort of thing for the moment, but perhaps an email would provide a more comprehensive response.
16:23:49 <odyssey4me> Unfortunately for some reason my subscription to openstack mailing lists is just not working. I need to figure out what's gone wrong there.
16:24:10 <defionscode> #action email openstack infra mailing list
16:24:35 <odyssey4me> It may be better if defionscode does it, given that he'll be able to outline the history and such.
16:25:02 <defionscode> yep i'll do it
16:25:10 <defionscode> #link openstack-infra@lists.openstack.org
16:25:35 <odyssey4me> thanks defionscode - appreciate it
16:25:41 <defionscode> np
16:25:50 <defionscode> ok another poll of sorts...
16:25:55 <odyssey4me> please feel free to quote mnaser, myself and/or cloudnull liberally
16:26:10 <odyssey4me> (assuming mnaser is cool with that :p)
16:26:15 <mnaser> yes, an email would be good and i can chime in as well
16:26:21 <defionscode> @shepdelacreme suggested having each role have it's own independent docs and then just linking to them directly from the root lockdown repo (and probably the landing page)
16:26:28 <odyssey4me> I'll try and sort out my mailing list issues.
16:26:39 <defionscode> any objections to that format?
16:26:50 <defionscode> AH would be fused in with the RHEL7 STIG role docs
16:26:58 <mnaser> odyssey4me: try to ping fungi, he has mentioned that he's seeing issues with mail delivery
16:27:01 <odyssey4me> defionscode not for me - that's the simplest way to get it going IMO...
16:27:14 <defionscode> cyberpear thoughts?
16:27:30 <cyberpear> looking
16:27:57 <shepdelacreme> the docs "template" I built from the AH docs for the new RHEL7 STIG docs can easily be copied to new roles and then the docs are generated pretty automagically
16:28:28 <defionscode> mainly b/c shepdelacreme is a boss
16:28:34 <cyberpear> Might be nice to have consolidated docs, or at least good linking between them, but no strong opinion
16:28:53 <defionscode> i think we can have that as a future goal
16:29:08 <cyberpear> If there's a way to do it w/o copy/paste, I'm a fan of DRY (don't repeat yourself) as much as possible...
16:29:22 <defionscode> but for step1 as odyssey4me said, it's the simplest way atm (manual linking)
16:29:28 <cyberpear> sounds reasonable
16:29:38 <defionscode> agreed then
16:30:00 <defionscode> #agreed each role to have independent docs that are then linked in the root repo README and the landing page
16:30:27 <defionscode> ok im out of topics i wanted to cover, cyberpear shepdelacreme anything ya'll wanted to discuss?
16:31:04 <cyberpear> Any thoughts on yum-cron in RHEL7-STIG? https://github.com/MindPointGroup/RHEL7-STIG/issues/204
16:31:26 <shepdelacreme> nothing from me
16:31:47 <dericcrago> I'm here because I noticed shepdelacreme was talking about RHEL7 CIS a couple meetings back
16:32:20 <cyberpear> (otherwise, V2R1 updates still pending... got a complaint it was not done, but not a chunk of time to do it :P)
16:32:27 <defionscode> cyberpear +1 on making it optional
16:33:04 <defionscode> dericcrago yeah that's something that would be nice, it probably wouldn't be _that_ hard given the amount of overlap
16:33:25 <dericcrago> I've implemented a RHEL7 CIS role internally (I was unaware of lockdown when I started it), but I might be able to provide some feedback / updates, depending on what you're looking for
16:34:15 <defionscode> dericcrago well all that is needed is to make a role that is formatted like the RHEL7 STIG role, just with CIS specific descriptions, rule ids, etc
16:34:26 <defionscode> and in CIS-specific sequence
16:35:09 <shepdelacreme> we have https://github.com/MindPointGroup/RHEL7-CIS that we want to bring in line with the RHEL7 STIG format/testing/etc
16:35:18 <dericcrago> is that what was meant by `I wanted to work on starting to bring the current CIS role in line with the standards we set out for the STIG roles`?
16:35:28 <defionscode> yes
16:35:42 <defionscode> it's more about style and testing methodology than anything else
16:35:58 <defionscode> it's what keeps us sane in terms of maintainer brain-capacity
16:36:03 <dericcrago> sure
16:36:04 <shepdelacreme> also finishing the unimplemented items :)
16:36:24 <defionscode> shepdelacreme do you have an opinion on yum-cron?
16:36:41 <defionscode> i think what cyberpear proposes makes sense
16:36:41 <cyberpear> how much overlap is there with your internal role and the one above?  (I haven't checked the implementation status of the one above, haven't needed it yet)
16:36:47 <shepdelacreme> I think optional is a good choice
16:37:00 <dericcrago> I've got RHEL7 Server - Level 1, it'll be interesting to compare / contrast the different approaches
16:37:19 <cyberpear> #agreed make yum-cron optional
16:38:31 <defionscode> cool, what else?
16:38:59 <cyberpear> dericcrago, any chance of getting yours published to github?
16:40:18 <dericcrago> seems unlikely, but I could probably contribute on anything missing to the lockdown rhel7 cis role
16:40:46 <dericcrago> or even help with standardization
16:40:50 <cyberpear> sounds good.  Likely you could add tasks you may have complete in yours that are missing from ours
16:41:09 <dericcrago> I'm not sure how interested we are in maintaining our version longterm, was just unaware of the lockdown version when we started
16:41:31 <defionscode> cyberpear fyi dericcrago is a mindpoint employee
16:41:44 <cyberpear> good to know
16:42:14 <dericcrago> huh?
16:42:43 <defionscode> oh ha we have a guy named deric and I assumed it was that deric
16:42:47 <defionscode> now I feel dumb
16:42:49 <defionscode> disregard
16:43:01 <cyberpear> heh
16:43:04 * defionscode hangs head in shame
16:43:07 * cyberpear disregards...
16:43:10 <dericcrago> :)
16:43:49 <defionscode> it's interesting b/c he also uses CIS benchmarks for RHEL on a contract we have with NASA
16:44:07 <defionscode> so it lined up and i got ahead of myself lol
16:44:36 <dericcrago> yeah, and there definitely aren't that many 'deric' (spelled that way) out there
16:45:17 <defionscode> welp that embarrassment aside, what else is desired to be discussed?
16:47:13 <cyberpear> I don't have anything else for today.
16:47:17 <dericcrago> probably not meeting worthy, but what is the connection between mindpoint and ansible lockdown?
16:47:33 <defionscode> oh that's a fine question
16:47:59 <defionscode> once upon a time I worked as a contractor for NASA, mindpoint was also a contractor there
16:48:02 <defionscode> we became friends
16:48:10 <defionscode> I went on to work for Ansible
16:48:41 <defionscode> and drawing inspiration from a role that sdoran created, we (mindpoint, sam, and I) launched ansible-lockdown
16:49:05 <defionscode> thus starting a formal mindpoint-ansible relationship
16:49:06 <defionscode> which is now a mindpoint-redhat relationship
16:49:07 <defionscode> and now I work for mindpoint
16:49:30 <cyberpear> great to get the backstory!
16:49:30 <dericcrago> oh, ok, thanks for the explanation
16:49:37 <defionscode> dericcrago happy to give more details if you'd care to learn more specifics
16:49:59 <cyberpear> (you may need to hand out #chair before ending the meeting)
16:50:05 <defionscode> haha
16:50:20 * cyberpear is always curious about the details :P
16:51:11 <defionscode> a 'secret', we're working with redhat to develop joint pro-services around lockdown content which should help with role maturity too
16:51:30 <cyberpear> awesome!
16:51:47 <dericcrago> one last, ansible core has kind of went back and forth with submodules, and ultimately ended up with a large monolithic repo, do you see that happening with lockdown?
16:52:14 <cyberpear> no, ansible-lockdown is more like an ansible-galaxy component
16:52:17 <cyberpear> rather than an ansible module
16:52:33 <defionscode> the only submodules will be in the ansible-lockdown repo but more as an FYI
16:52:34 * cyberpear speaks for himself
16:52:45 <defionscode> installing roles directly from their own respective repos is the "right way"
16:52:47 <dericcrago> yeah, I meant submodules in the git sense
16:53:49 <defionscode> the submodules in the lockdown repo are more of a lazy approach to get "everything" all at once if for some odd reason you really do want all the repos at once
16:53:57 <cyberpear> re the pro-services, I'd chatted w/ one of their folks and strongly pointed him toward ansible-lockdown
16:54:35 <defionscode> solid
16:55:00 <cyberpear> "just works" vs an initial impression of "100% compliant is 100% broken"
16:55:17 <cyberpear> (was back in november, I think)
16:55:58 <defionscode> cyberpear not sure i follow now
16:56:06 <defionscode> dericcrago did that sufficiently answer your question?
16:56:41 <dericcrago> yes, it did, thanks
16:57:44 <dericcrago> please let me know if there's any low hanging fruit regarding CIS RHEL 7 anyone (shepdelacreme?) would like me to look at
16:58:15 <dericcrago> I'll try to attend these meetings regularly if for no other reason to be a fly on the wall
16:58:23 <defionscode> dericcrago i think the easiest thing right now would be to check it out and open up issues (or PRs) where you think it falls short
16:59:15 <defionscode> also we welcome any and all flies in this meeting!
16:59:46 <defionscode> this channel and working group welcomes all forms of life
17:00:00 <defionscode> we're now at the top of the hour, wrapping it up, thanks everyone!
17:00:05 <defionscode> #endmeeting