16:10:42 #startmeeting Ansible Lockdown Working Group 16:10:42 Meeting started Thu Jun 27 16:10:42 2019 UTC. 16:10:42 This meeting is logged and archived in a public location. 16:10:42 The chair is cyberpear. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:10:42 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:10:42 The meeting name has been set to 'ansible_lockdown_working_group' 16:10:48 sorry folks...meetings all day 16:10:55 #chair shepdelacreme dfed 16:10:55 Current chairs: cyberpear dfed shepdelacreme 16:11:23 #topic core-supported modules 16:11:37 #info there was a suggestion that we limit ourselves to core-supported modules 16:11:46 I did not say limit, I said favor when possible 16:11:59 I don't see a good reason to limit; use the best tool for the job 16:12:02 and the argument is around supportability. 16:12:28 e.g., the best tool for modifying ini files is `ini_file`, IMO 16:12:32 There was, when I was head of support, plans to split RH's official support of community modules off, leaving "core" modules as supported with SLA. That afaik is still in place. 16:12:47 I think it makes sense to say we "prefer supported core modules" 16:12:48 and many of the community modules require epel, which customers of our cannot use 16:13:03 I'm okay avoiding modules that require epel 16:13:17 should work w/ RHEL out-of-the box, is my opinion 16:13:22 i would also argue that you really want 'full file control' as 'partial file updates' can be easily overriden by duplicate entries with more precedence 16:13:33 specially in the ini case 16:13:49 many of the non-core modules may require epel or other package managers in the future if they get split out 16:13:53 (things in rhel-7-server-optional-rpms are also not supported, for example) 16:14:26 again, this also has to do with SLA. core supported modules have action to redress under an SLA, community does not. 16:14:32 limiting the amount of extra stuff that needs to be installed, outside of the core helps usability as well as supportability 16:15:34 what non-core modules are we using today? 16:15:48 (at least `replace` and `pamd` that I know of, but I haven't checked b/c it's never mattered) 16:15:56 I haven't done a full audit, but I was focusing on using core supported as I finish out the stig role for rhel 7 16:17:22 shepdelacreme: is there a particlar thing you're referring to wrt installing extra stuff? 16:17:30 again when possible to favor it. 16:18:44 To help w/ reliability, it probably would make sense to add some (more) integration tests into core ansible for the non-core modules we're using 16:19:19 maybe, but that still doesn't get us SLA support. 16:19:44 Just a quick intro for everyone that isn't aware. dfed is previously of the Ansible team for many years and is now with us at MindPoint Group leading up our efforts to get the STIG and other hardening roles sorted/etc. He is a core maintainer from our side as myself and defionscode are busy with other things. 16:20:26 As far as extra stuff...I'm would just like to limit the amount people need to install in the future. i.e. if non-core gets split out that becomes an issue for use 16:20:45 I have no definitive timeframe for when that happens, btw, but I would llike to head off the headacche 16:21:01 how often has SLA been needed for modules we use, as we use them? 16:21:07 I pinged appnel and michelle perz to understand how that is progressing in product planning 16:21:08 I'm only aware of one breakage of pamd 16:21:55 in that case, the `pamd` module had no integration tests in ansible, but only unit tests 16:22:01 @cyberpear not a good metric. The first customer of mindpoint that has issues comes to me and I may need to act on a timeframe, having a partner relationship or a customer relationship in ansible support is a different path than community maintenance. 16:23:12 and down the road when the split happens, this saves us headache. 16:23:28 now I'm not saying don't use community atm, I am saying when given a choice, favore core. 16:23:29 what about copying particular tasks from scap-security-guide, then calling RH for support of that? 16:23:56 it's BSD-3-Clause, so compatible w/ MIT, if I understand 16:23:58 RH support path for that may not end up in ansible support's queue. 16:24:08 it may end up with the openscap team 16:25:25 Also, they are only going to support the tasks if you are using/applying them with the ssg 16:25:34 not if you copy them into another playbook for use 16:25:38 bingo 16:26:06 not to mention they are often just command or shell tasks :( 16:26:23 #agreed prefer core-supported modules when possible 16:26:30 TY. 16:26:55 btw I'll resubmit from a new branch to clean up the other things. 16:27:10 I need to get a bunch of things plumbed correctly now that I have settled in 16:27:15 In this particular case, I think we should just plop the snipped into the conf.d directory w/ `copy` (or `template` if you prefer) 16:27:35 don't try to use lineinfile, because that doesn't work well for managing ini files 16:27:40 that works. I'd template b ut that's muscle memory. I wasn't aware copy populated the vars in the file 16:28:19 especially for single-digit files, I greatly prefer `copy` w/ `content` 16:28:35 * dfed shrugs 16:28:39 I have no argument against that 16:28:44 tiny files, but do what's easiest for you 16:29:28 shepdelacreme would prefer to have a shorter .yml but that's kind of a lost battle unless we want re-organize 16:30:07 yeah 16:30:12 I mean, shorter and more elegant is fine, but if it compromises readability and easy understanding that's an issue. 16:30:12 #agreed use `copy` or `template` instead of `ini_file` when config snippets are supported 16:30:38 the cat2 file is unweildy but not worth splitting stuff out for now 16:30:54 it is a monster, to be sure. 16:31:30 #topic ansible-hardening integration, organization 16:32:01 so, can I get a recap on thiis topic? being new(ish) and all? 16:32:22 there was some agreement to integrate openstack's ansible-hardening and ansible-lockdown 16:32:28 right got it. 16:32:34 w/ ansible-lockdown being the name of the merged topic 16:32:39 shepdelacreme: may be able to provide more details 16:33:05 I remember this in the fog of my first couple weeks, vaguely. I think we were talking about difference in format/style of the roles 16:33:22 I attempted to use ansible-hardening against an ubuntu 16.04 system, and got my first good look inside... 16:33:30 how'd that go? 16:33:48 looks like it was a rhel7 stig role that was tweaked to allow it to run on other OSes 16:33:57 um. that's problematic 16:33:59 so it doesn't specifically implement the ubuntu STIG 16:34:05 yeah the goal with this was to support applying the rhel7 stig to non-RHEL systems like Ubuntu and what not 16:34:26 there's now an official ubuntu 16.04 stig at V1R2 16:34:39 there's a ubuntu stig though...the rhel one will get specific into rhel-ish things in filesystem and location and env that may be troublesome 16:34:42 I think it makes more sense to just build STIGs specifically for systems that have a STIG defined and extend the RHEL7 STIG to be usable on RHEL-alike systems 16:34:47 yeah 16:34:50 agreed with that 16:34:59 I did a bit of comparison, and there's a lot similar, but DISA seems to have done a poor job of the SRG references between the 2. 16:35:12 hm. 16:35:17 of course they did...its DISA 16:35:20 LOL 16:35:45 they reference the "follow the STIG" SRG requirement several times as a reference for particular requirements 16:36:00 yeah, I LOLed 16:36:16 ...Where's my facepalm gif? 16:36:23 the base requirement for including a particular task in the STIG is an upstream requirement to "follow the STIG"... 16:36:31 (but we're a bit off topic, I guess) 16:36:48 ok so what should we do to adopt the hardening stuff? 16:37:07 a lot of it maps over exactly 16:37:16 exact same checks and remediations 16:37:25 ok 16:37:52 we should, at some point, talk about moving the repos into the ansible-lockdown github org, but that's off topic for now 16:37:52 I was toying w/ the idea of re-using ansible-hardening's "topic" split-out, perhaps further splitting that out by severity 16:38:06 just in the interest of not having a 2-3k-long tasks file 16:38:08 oh, that might be interesting. 16:38:28 we'd previously agreed to just keep our severity break-out but it might be worth reconsidering 16:38:37 in fact some category split, then another severity split could work mapped out correctly for more controls in the vars as to which to run 16:38:51 the topic part could help that 16:39:25 we also can split out the vars files w/ `defaults/main/tasks.yml`, `defaults/main/config.yml`, etc 16:39:31 same for vars, tec 16:39:33 etc 16:39:38 agreed 16:39:53 (somehow that feature didn't make it into the anisble release notes so I just became aware of it; available since 2.6) 16:40:20 I remember some interesting support tickets on that one 16:40:35 that would def help with limiting file size and git commit blast radius as the tempo of changes picks up 16:40:55 regardless, let's dig in there and see what we can improve in our design of the roles 16:41:07 agreed @shepdelacreme 16:41:28 I still haven't had the chance to demonstrate my "all-in-one linux SRG/STIG" role idea, but hopefully I can get to it shortly 16:41:57 (key features being that it keeps the usability and configurability of the RHEL7-STIG role) 16:42:08 interesting 16:42:48 so you'd use 'rhel7stig_my_config' vars for rhel7 customizations, but ubuntu16stig_ or equivalent for those OSes 16:42:59 perhaps w/ some generic name that would work for both 16:42:59 brb y'all I have to let the dog out. 16:43:54 would implement using the `vars` and perhaps `varnames` lookups, but that implementation wolud be hidden in `vars/` where no one should ever have to look 16:45:47 #info worth evaluating a break-out of role tasks by category like ansible-hardening 16:46:14 I think ssg has their own category system, but I haven't paid too close attention 16:47:10 I wonder if there is a STIG or SRG categorization we can reference (aside from cat 1, 2, 3 obviously) 16:47:33 if not then I think most items can be logically placed in different buckets 16:47:49 i.e. auditd, authentication, ssh, etc 16:47:50 #info consider splitting `defaults/main.yml` into `defaults/main/tasks.yml`, and `defaults/main/config.yml` (bikeshed names) 16:48:05 does CIS have good categories? 16:48:37 maybe...they didn't used to but they have mostly standardized now I think 16:50:12 something like CISSP has security "domains" but those don't really map here 16:53:46 dfed: FYI, you can force-push rather than opening a new PR. `git push --force-with-lease` is your friend 16:54:18 fair. 16:54:29 I mostly wass using that as a window to watch the travis/testing pickup 16:54:49 which is why you got sloppy PRs. They'll be more polished going forward. 16:55:20 I think github also allows you to mark them as "draft" PRs, and adding WIP to the title at the start 16:55:30 does it? TIL 16:55:36 *does it? wow bad keyboard 16:55:45 then add a comment like ready_for_review once ready 16:55:53 I'll do that going forward. 16:56:22 does anyone know how well the ansible-hardening does relative to the ubuntu 16.04 stig? 16:56:31 (today, that is) 16:56:49 I've not poked at it to evaluate, but I can put that on my list 16:57:48 I don't have time now to do an audit, but I've audited the RHEL7 and RHEL 6 STIG roles, and they are phenomenal. 16:58:35 and the shortcomings of RHEL7-STIG are well documented in https://github.com/MindPointGroup/RHEL7-STIG/issues/44 16:58:56 should we adopt those to our own instead of me writing new tasks per our format? 16:59:20 I assume you mean the stig roles from harden ing 16:59:25 sorry 16:59:31 lockdown roles are phenomenal 16:59:36 got it. 17:00:03 only 7 items outstanding for RHEL7-STIG in my mind for non-GUI uses 17:00:14 working on those ;) 17:00:15 (most of the others are compliant in a default configuration) 17:00:42 I don't think I have anything else on topic 17:00:46 honestly I don't know how often we'll get the GUI uses in the field, but we'll see 17:00:49 any other news/announcements/plans to discuss? 17:01:03 none from me. 17:01:20 @shepdelacreme you good? 17:01:29 yup I'm good thanks 17:01:31 I'm starting to see GUI more often, but sometimes it's b/c folks are in a windows world and not comfortable w SSH 17:01:41 thanks all! 17:01:48 * dfed waves 17:01:50 #endmeeting