17:02:30 <defionscode> #startmeeting Ansible Lockdown Working Group Meeting 17:02:30 <zodbot> Meeting started Thu Nov 15 17:02:30 2018 UTC. 17:02:30 <zodbot> This meeting is logged and archived in a public location. 17:02:30 <zodbot> The chair is defionscode. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:30 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:02:30 <zodbot> The meeting name has been set to 'ansible_lockdown_working_group_meeting' 17:03:13 <treyp_> here 17:03:17 <defionscode> lets pick up off where we left off for that last agenda and then hit the items that shepdelacreme has brought up 17:03:19 <defionscode> welcome treyp_ 17:03:32 <defionscode> #topic Galaxy 17:04:02 <defionscode> should we automate tags/pushes to galaxy? 17:04:40 <defionscode> I lean slightly to no simply because there's not an obvious clean way of doing proper semver in the build process atm 17:04:55 <shepdelacreme> what would that process look like? 17:05:19 <defionscode> in the CI config file add ansible galaxy commands that will run if the tests pass 17:05:31 <shepdelacreme> I don't think cutting a new release every time something is merged into devel makes sense 17:05:43 <bcoca> fyi, calendar has meeting 1h earlier 17:05:53 <bcoca> probalby ics file needs to be updated 17:06:00 <defionscode> bcoca: yeah but readme for the meeting says 12pm EST 17:06:03 <cyberpear_> DST 17:06:05 <bcoca> iirc it doesn't do DST 17:06:15 <defionscode> it doesnt 17:06:19 <bcoca> why you should update ics then 17:06:36 <defionscode> or just peg it to UTC, we'll vote on that later 17:07:00 <defionscode> cyberpear_ thoughts/opinions on automated tags? 17:07:15 <defionscode> right now seems like 2 nays 17:07:41 <cyberpear_> Seems like it should be easy to have Dev numbering system that is a sub number of main releases, but I don't actually use Galaxy so no strong opinion 17:08:02 <bcoca> galaxy is going to require semantic versioning to handle versions 17:08:22 <defionscode> cyberpear_: yeah semver can handle that but i think it'll be safer for one of us to cut a new release when it's ready 17:08:29 <bcoca> you are still able to use anything (commit hash, etc) for install, but version conflict management will only happen with semver 17:08:41 <defionscode> yep 17:08:43 <shepdelacreme> on a related topic is there a way with CI to have galaxy automatically run a refresh/import when we create a new tag/release in github? 17:09:04 <defionscode> ¯\_(ツ)_/¯ 17:09:14 <bcoca> ansible-galaxy cli can be used ti push , so i guess you can automate that way 17:09:36 <shepdelacreme> ok 17:09:47 <defionscode> shepdelacreme: well we wouldnt do that via CI b/c ci isn't trigged on a tag push 17:09:50 <defionscode> afaik 17:09:55 <bcoca> issue is credentials mgmt, i know shippable and travis have a way to handle those w/o disclosing 17:10:22 <bcoca> defionscode: depends, you can make tags work as commits 17:10:26 <defionscode> bcoca: we're using travis right now but will be moving to openstack's testing infra 17:10:42 <bcoca> one zuull to rule them all! 17:10:48 <defionscode> ha! 17:10:58 * bcoca mixes franchises 17:11:21 <gundalow> defionscode: AFAIK github.com/ansible-network/* releases are done via Zuul on tag, just trying to find the role for that 17:11:34 <defionscode> #agreed no automated tagging in CI on PR merge 17:12:09 <defionscode> gundalow: oh i knos it's possible but given the nature of our project it might not be the safe thing to do 'always' 17:12:25 <bcoca> unless you only accept 'complete' PRs 17:12:28 <gundalow> Sure, you could make it depending on $something 17:12:31 <defionscode> #idea investigate looking into triggering CI via git tag push 17:12:53 <gundalow> oh. github.com/ansible-network/* pushing to Galaxy is when someone tags a release, not every merge 17:13:03 <defionscode> gundalow: yeah that workflow is saner 17:13:09 <bcoca> agreed 17:13:11 <defionscode> on git tag, that totally works 17:13:34 <gundalow> https://github.com/ansible-network/zuul-config/blob/master/zuul.d/jobs.yaml#L80-L89 17:13:55 <defionscode> gundalow: can you #link that? 17:13:56 <gundalow> https://github.com/ansible-network/zuul-config/blob/master/playbooks/publish/galaxy.yaml 17:14:58 <gundalow> #info github.com/ansible-network/* are Galaxy repos. AFAIK Zuul is configured to push a release to Galaxy on `git tag`, see https://github.com/ansible-network/zuul-config/blob/master/zuul.d/jobs.yaml#L80-L89 and https://github.com/ansible-network/zuul-config/blob/master/playbooks/publish/galaxy.yaml as in #ansible-network for more info 17:15:17 <defionscode> next item, pulp builds 17:15:21 <shepdelacreme> that works...we can replicate that behavior once we move to openstack and zuul 17:15:50 <defionscode> does it make sense to provide 'offline' packs for lockdown stuff? I dont think it'd be hard given there is already ansible_pulp 17:16:15 <bcoca> defionscode: galaxy aims to do that in the background, use pulp for role/content distribution, is it needed right now or can it wait for that? 17:16:22 <defionscode> but not sure if anyone would get value from it, mainly b/c agency users aren't really vocal on mailing list, etc 17:16:54 <defionscode> bcoca: not sure? i think have $FOO agency users that leverage this in air gapped places 17:17:10 <cyberpear_> I'm pretty sure Paul can do it without any help from us. Again, I just grabbed the git repo where needed 17:17:18 <bcoca> defionscode: just to avoid dupe effort, if you can just mirror the galaxy pulp 17:17:19 <shepdelacreme> how does pulp solve this? I'm not familiar with pulp builds 17:17:21 <defionscode> it's more about the role being easy to store in USB/CD for transport more than the galaxy piece 17:17:32 <cyberpear_> Pulp 17:17:34 <defionscode> shepdelacreme: i believe it tars up the role and dependencies 17:17:38 <defionscode> but i dont know for sure 17:17:41 <shepdelacreme> hmm ok 17:18:10 <bcoca> pulp is basically a 'package repo' that stores the actual packages vs references to them (previous galaxy) 17:18:33 <shepdelacreme> having worked in that world...getting ansible and dependencies and role content over to the air gapped network was always a pita 17:19:18 <defionscode> bcoca: do you know if 'new' maser-based galaxy will have the option to pull down the pulp artifact as-is? ie, not-extracted? 17:19:23 <defionscode> if so, then i vote we wait 17:19:25 <bcoca> i would just check with galaxy team to see if their work is easy to levarage 17:19:55 <bcoca> defionscode: idk, ^ hence i would first talkt to the team (chouse?) and see if that can be reused before buliding your own 17:20:00 <defionscode> #action check with galaxy team about leveraging the future built-in pulp mechanism 17:20:04 <defionscode> yep ok 17:20:18 <defionscode> we'll hold off on deciding based on that then? work for you shepdelacreme and cyberpear_ ? 17:20:19 <bcoca> just seems worth checking before doing same thing 17:20:23 <defionscode> yep i agree 17:20:34 <cyberpear_> Yes 17:20:37 <shepdelacreme> yes 17:20:40 * bcoca is lazy that way 17:20:56 <defionscode> #topic development experience 17:21:07 <defionscode> first subtopic 17:21:38 <defionscode> i have the MVP workings of a docker based 'tinkering' tool that allows you to run a single rule from the role against a centos container 17:21:49 <defionscode> which makes iterating a little easier 17:22:12 <defionscode> shepdelacreme: cyberpear_ is that something that would help you guys out too? if so I can make a sort of /tools dir and add that in there 17:22:44 <defionscode> could probably make it something you could add to $PATH even to make it even smoother 17:23:45 <cyberpear_> Not a bad idea. hacking/ 17:23:56 <shepdelacreme> yeah I think that helps...as is right now I run molecule and pass it tags to run a specific rule or group of rules 17:24:09 <shepdelacreme> I'd be interested to see how your solution works 17:24:22 <cyberpear_> Similar to ansible itself 17:24:34 <defionscode> ok cool wfm i'll put that on my todo's 17:24:50 <shepdelacreme> Like right now I just run something like: molecule converge --scenario-name vagrant -- --tags RHEL-07-010118 17:24:59 <defionscode> #action defionscode to create hacking dir with single-rule dynamic test setup 17:25:46 <defionscode> molecule way isn't bad, feels a little slow b/c of the setup/tear down stuff but maybe that's cleaner? 17:25:58 <shepdelacreme> ah yeah...I don 17:26:52 <bcoca> i was just looking at project the other day that did this well .. ansible-builder? 17:26:58 <shepdelacreme> I don't run the whole cycle every time. I'll do create and then run just converge so it stays up between runs 17:27:18 <defionscode> ah interesting 17:27:39 <defionscode> bcoca: link? 17:28:03 <cyberpear_> Ansible - blender 17:28:11 <bcoca> ^ i think that is it 17:28:44 <defionscode> my googling doesnt turn up anything obvous 17:29:03 <defionscode> but shepdelacreme's idea seems like it would accomplish the same thing too 17:29:04 <shepdelacreme> I just get ansible roles for blender render farms lol 17:29:12 <bcoca> i cannot find it now, but it was posted in internal slack last week 17:29:34 <defionscode> it would be easy to wrap molecule in a bash script to PATHify it too 17:29:52 <shepdelacreme> defionscode: maybe we just need to flesh out the testing docs a bit more to document how people can iterate on specific rules? 17:30:03 <defionscode> using converge didnt occur to me before 17:30:19 <defionscode> yeah 17:30:32 <shepdelacreme> it is annoying if you want the host to reset to the base/starting config though 17:30:52 <defionscode> cant you just destroy it at that point? 17:30:57 <shepdelacreme> with docker its not a hugely long wait but with vagrant it can take forever 17:31:05 <defionscode> oh right 17:31:15 <defionscode> you havent tried converge with the docker stuff? 17:31:22 <shepdelacreme> yeah it works with docker 17:31:23 <defionscode> molecule/docker i mean 17:31:45 <defionscode> #idea use molecule converge for single-rule iteration 17:32:11 <defionscode> #idea create bash wrapper for converge iteration 17:32:44 <defionscode> next item 17:33:04 <defionscode> cyberpear_: shepdelacreme should we re-add oscap into the CI process to further constrain pass/fail criteria? 17:33:29 <defionscode> in tandem with the oscap_facts module I have PR open for, we could add it in rather easily 17:33:48 * defionscode knows he stills has to update the PR to not abuse fail_json 17:33:49 <cyberpear_> Yes, plus that helps keep ssg up to date 17:33:54 <shepdelacreme> I'm good with that. 17:34:06 <defionscode> ok 17:34:18 <shepdelacreme> Curious though. It would pass/fail based on a score we set right? 17:34:23 <defionscode> the PITA is the fault DISA SCAP content for Rel2 17:34:27 <defionscode> on a % score yeah 17:34:31 <defionscode> at the severity level 17:34:40 <defionscode> (or total if we prefer) 17:34:46 <defionscode> but I think at severity level is better 17:35:04 <shepdelacreme> Would be nice and rather cool if we could track pass/fail status of each rule. Then fail a PR if a rule goes from pass -> fail. 17:35:23 <defionscode> #agreed re-integrate oscap results into CI pass/fail criteria 17:35:36 <defionscode> #idea track pass/fail status of each rule 17:36:17 <defionscode> shepdelacreme: I agree, that wouldn't be hard, we'd prob's have to template a YML file and store in S3 or something...maybe in git, but i hate the idea of making commits in git from CI 17:36:57 <shepdelacreme> yeah...storing the previous result in S3 could work. I dislike having to commit the results file into the repo 17:37:42 <defionscode> #idea store per-rule results in S3 or something similar 17:37:58 <defionscode> oh on that note 17:38:25 <defionscode> shepdelacreme: and cyberpear_ which benchmark file should we default too? I err on the side of using the DISA content vs SSG 17:38:32 <defionscode> but DISA stuff wont run on Centos 17:38:47 <defionscode> SSG stuff runs on both but it's not up to date 17:38:56 <defionscode> as of a cpl weeks ago anyway 17:39:19 <defionscode> also DISA's stuff seems faulty at the present as documented in the GH issue 17:39:20 <cyberpear> DISA vs RHEL and ssg vs both? 17:39:55 <defionscode> hmm, we _could_ but that would make tracking trickier given the disparity in versions 17:40:02 <defionscode> like banner for example 17:40:07 <defionscode> would pass SSG content AFAIK 17:40:09 <defionscode> but fail DISA 17:41:07 <cyberpear> I've been operating as "satisfy DISA", ignore SSG results for items DISA benchmark covers, satisfy remaining SSG 17:41:29 <shepdelacreme> so you can't use the DISA xccdf file against CentOS ? 17:41:33 <cyberpear> unless a particular rule (disa or ssg) is broken 17:41:44 <cyberpear> you can hack the disa xccdf to run against centos 17:42:03 <cyberpear> s/redhat-release-server/centos-release/g and s/6Server/6/g 17:42:10 <defionscode> yeah, not out of the box you cant because of the OS check 17:42:55 <cyberpear> otherwise, create a bogus package called "redhat-release-server" and install it on the centos machine... 17:42:58 <defionscode> cyberpear: ah yeah i was operating under the assumption of the SSG STIG profile 17:43:04 <defionscode> i forget there is a more broad one 17:43:27 <defionscode> so either a patch file or a dummy rpm 17:43:48 <defionscode> i think i prefer the patch file 17:44:00 <defionscode> it's more obvious to outsiders/new-comers i'd think 17:45:15 <cyberpear> +1 to a scripted patching of DISA benchmark 17:47:04 <defionscode> cyberpear: you up to take that one? make patch file, add it somewhere 17:47:40 <defionscode> shouldn't be hard to do since it seems you know what bits in teh xccdf need to be swapped 17:47:48 <cyberpear> yeah, I should be able to get that 17:47:53 <defionscode> dope 17:48:08 <defionscode> #action cyberpear to create patch file to make disa xccdf use-able in centos 17:48:49 <defionscode> odyssey4me: mnaser either of you around? 17:49:03 <mnaser> defionscode: il 17:49:06 <mnaser> I’m 17:49:16 <mnaser> I’m in a cab? Hah. It’s the openstack summit this week 17:49:20 <mnaser> So most of us are there :) 17:49:27 <defionscode> ah very cool 17:49:36 <defionscode> also +1 to you for having a mobile client 17:49:53 <defionscode> mnaser: two questions im not sure if you have the answer to 17:50:05 <defionscode> 1) any insight on getting us access to openstacks testing infra? 17:50:08 <mnaser> Sure. I can try. 17:50:36 <mnaser> Yes. That’s possible. I would try to ping clarkb on #openstack-infra or email openstack-infra mailing list 17:50:39 <defionscode> and 2) have you a set opinion on deferring ubuntu 16 compatibility to an ubuntu 16 stig rule given there is an upstream benchmark for that now? 17:50:50 <defionscode> ok 17:51:06 <defionscode> #action defionscode to ping clarkb on #openstack-infra/mailing-list 17:53:08 <defionscode> #topic domains from AH 17:53:15 <defionscode> shepdelacreme: this is your agenda item 17:53:43 <defionscode> iirc the AH team doesnt care how the content is organized, i think it's easier to maintain by severity as we do now 17:54:19 <shepdelacreme> yeah sorry 17:54:35 <shepdelacreme> I just wanted to get buy in before I removed it all 17:54:50 <shepdelacreme> if no one is partial to the "domains" stuff in the docs I will cut it 17:55:00 <defionscode> cyberpear: opinions on that? i vote cut it 17:55:25 <cyberpear> haven't looked closely. Sounds like what we currently have some (incomplete) tags for 17:55:34 <cyberpear> no strong opinion 17:55:55 <cyberpear> most folks applying the STIG are required to have the whole thing 17:56:03 <shepdelacreme> ok...I will cut it. Adding it back in is easy enough if we decide to organize by domains/tags 17:56:09 <defionscode> #agreed on not having domains 17:56:30 <defionscode> #topic contrib stuff from AH 17:57:07 <defionscode> so on that, i think we wanted to keep a sort of 'extra.yml' or something to preserve backwards compat with AH but maintership/updates on that would rest with the AH team ie odyssey4me mnaser etc 17:57:21 <shepdelacreme> So it seems like the AH role has some stuff that isn't in the stig and that is what the "contrib" stuff is... 17:57:48 <shepdelacreme> it looks like for now the only thing in the documentation is C-00001 - Disable IPv6 17:57:55 <mnaser> Yeah. I think that should be okay if we have to make things so they continue to work for everyone :) 17:57:59 <shepdelacreme> but there might be other contrib items that just aren't documented 17:58:37 <defionscode> mnaser: have you thoughts on the ubuntu 16 stuff? 17:58:52 <defionscode> on making it it's own standalone role since it has a STIG benchmark 17:59:11 <mnaser> defionscode: why not just have it in the same role with a conditional 17:59:16 <mnaser> That would make testing easier too 17:59:25 <mnaser> In upstream openstack too 17:59:47 <defionscode> that would explode the content to roughly 2x 18:00:00 <mnaser> You’ll see Ansible hardening has a single entry point 18:00:01 <shepdelacreme> For people that use the STIGs for compliance/audit reasons they would want their Ubuntu hardening to follow the ubuntu STIG 18:00:06 <mnaser> And a rhel7stig folder 18:00:18 <defionscode> and would make not-obvious for ansible-galaxy based installations 18:00:21 <mnaser> We would add a ubuntu16stig folder and include things in that? 18:01:01 <mnaser> (Sorry, I really have to drop off but feel free to raise this in openstack-dev and I’ll be more than happy to clarify more over a mobile client) 18:01:09 <defionscode> it would not make testing easier from a oscap evaluation standpoint either 18:01:16 <defionscode> ok, will do 18:01:39 <defionscode> #action hit up openstack-dev about hardening split for ubuntu 18:02:01 <defionscode> #topic identifier for docs 18:02:19 <defionscode> shepdelacreme: you've been hacking away at that, would it be hard to just use both? 18:02:44 <shepdelacreme> we can include both in the front matter yes 18:02:47 <defionscode> from developing the STIG CLI there has only been one instance where the vuln ID was duplicated but i forget which two STIGs taht was 18:02:48 <cyberpear> +1 use both. The STIG is sorted by STIG-ID, but many things refer to the V-# 18:03:01 <shepdelacreme> but there sort of needs to be a "primary" for sorting/viewing 18:03:28 <defionscode> i think with sphinx there is still a good native search utility 18:03:53 <defionscode> let's do both and then keep the STIG id as primary? 18:03:57 <cyberpear> +1 18:04:03 <shepdelacreme> yeah there is...for the list of rules by category or whatever though I will switch from V- to RHEL-07 if everyone agrees 18:04:04 <defionscode> then if someone need to do a vuln id lookup they can use search? 18:04:11 <shepdelacreme> yeah 18:04:15 <defionscode> that's fine 18:04:20 <shepdelacreme> works for me :) 18:04:22 <defionscode> ok agreed then 18:04:43 <defionscode> #agreed keep stig ID as primary but include vuln ID in front matter 18:04:53 <defionscode> #topic open topics 18:05:05 <defionscode> cyberpear: shepdelacreme anything else ya'll want to cover? 18:05:28 * cyberpear created the github orgs ansible-lockdown and ansible-lockdown-sig 18:05:29 <shepdelacreme> real quick comment about my work on the docs and doc generator 18:05:44 <shepdelacreme> mystery solved! 18:06:04 <cyberpear> (btw, RHEL 8 beta dropped! Let's get started on the STIG! :P) 18:06:21 <shepdelacreme> just a heads up cyberpear you may or may not get an email from Github support 18:06:51 <defionscode> ooooo! 18:07:04 <defionscode> cyberpear: can you give us access! 18:07:06 <defionscode> ? 18:07:10 <cyberpear> yeah 18:07:15 <shepdelacreme> we were unsure who created those orgs haha 18:07:27 <defionscode> i am planing to build the script to gen the scaffolding for all the stigs soon 18:07:42 <defionscode> shepdelacreme: whats yoru docs comment? 18:08:20 <shepdelacreme> I need to standardize some of the content (like making sure all blocks: are named etc) so that the generator script can easily parse it 18:08:44 <shepdelacreme> so my docs PR will include those updates if everyone is fine with lumping all those changes together 18:10:00 <defionscode> if the role updates are purely on a `name:` scope, then idc 18:10:15 <defionscode> same with tags etc 18:10:17 <shepdelacreme> yeah...may include some tag fix ups as well 18:10:19 <shepdelacreme> ok great 18:10:34 <defionscode> cyberpear, opinions? 18:11:20 <cyberpear> generally, PRs or commits that only re-arrange what's already there should be separate from PRs/commits that make real changes. 18:11:50 <cyberpear> that makes it easier to do archaeology to figure out why things break or why they are the way they are 18:12:30 <cyberpear> so make it a separate commit and then it's probably fine as long as it stays a separate commit after the PR is merged. 18:13:01 <defionscode> cyberpear: so you consider `name:` and tag updates 'real' changes? 18:13:06 <cyberpear> no 18:13:29 <shepdelacreme> what about changing 'fix-cat1-.yml' to 'cat1.yml' 18:13:30 <cyberpear> not familiar w/ the docs work 18:13:38 <defionscode> right, so if shepdelacreme PR has commits that include docs and tag/name updates then there shouldnt be a problem 18:13:53 <cyberpear> should be fine 18:13:57 <defionscode> cyberpear: we're making something that piggy backs off ansible-hardenings sphinx build proces 18:14:05 <shepdelacreme> docs work is all new content...doesn't change any function of the role itself 18:14:30 <defionscode> shepdelacreme: i think we settled that last meeting no? i think we're all good with removing the fix- prefix 18:14:45 <shepdelacreme> but I'm trying to make a script that parses the content in the tasks files to build the content for each rule in the docs 18:15:16 <shepdelacreme> right we did settle it...was just saying I will probably include that change in my PR 18:15:29 <defionscode> ah, sure 18:15:36 <defionscode> should have no logic impact 18:15:37 <shepdelacreme> I can split that stuff out into a separate PR that doesn't include the docs stuff though 18:15:44 <shepdelacreme> ok 18:16:08 <shepdelacreme> thats all I have then 18:16:15 <defionscode> cool 18:16:39 <defionscode> cyberpear (or anyone else) anything you want to discuss before wrap up? 18:16:57 <cyberpear> nothing from me. Sent those github invites. 18:17:19 <defionscode> dope 18:17:23 <defionscode> #endmeeting