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