DCA - Allow the demo to apply effortless-config seperate

[anthonygrees]

@ChefRycar
The demo is great but it scans using effortless-audit and then automatically applies the effortless-config habitat service, remediating the CentOS nodes very quickly.

This does not allow time for an Architect to talk through the DCA concept with the customer and then show the remediation being applied (effortless-config).

It would be great if we could apply the remediation via a flag in Terraform or simply 'hab svc load effortless-config' on the node command line and then show the Centos nodes being updated.

[NickRycar]

Talked a bit about this on slack, but throwing it in here so I'll remember.

So, because things aren't bootstrapped by traditional means, we'll need an alternative to the old-style run-list editing. Since everything's in hab, the path of least resistance seems to be to update effortless config to leave things unfixed or partially fixed initially, so a demoer can then promote the fix through bldr to demonstrate DCA.

Thought is that MVP would be instructions for how to do so on a demoer's personal origin, and that can be seeded in via variables instead of using the stock effortless origin.

Longer term, it probably makes sense to try deploying a private repo with the environment to better formalize the process.

[jmery]

@anthonygrees in the interim, would it be okay to show the scan history in A2 or is it fixing things too fast for them to ever show up as failed?

[NickRycar]

IIRC the first run shows up as failed, but the interval is such that the page quickly fills up with passing audits, and you can have to dig to get to the failure.

[smford22]

@anthonygrees @ChefRycar @jmery I am not sure that this is the best repo to tell DCA. It tells the story of EAS in which each layer of the stack is managed in the same 'one way to prod...' If we actually want to do a DCA or 'Zero Day Vulnerability' demo...I have improvised those very easily using existing repos. I think we could easily create one that is designed to tell that story.

Nat Parks in my mind is showing application lifecycle on top of infra that is hardened and compliant with our kit.

[NickRycar]

I've had the idea to do sort of a meta-repo where we could pull in whatever story elements are required. I've been using this one as my baseline, since it's the most "kitchen sink" repo of all the post-BJC materials, but probably worth figuring out how we'd want such a thing to be shaped so we can pull in/wrap useful content in repos like this one without duplicating a lot of work.

[jmery]

Possibly make use of tf modules @ChefRycar ? i just want to be wary of recreating the BJC hydra of development.

[NickRycar]

Indeed. I'll look into settin' something up.

[NickRycar]

Still looking at doing some rearchitecting here for a more permanent way to do a DCA-style demo, but for the time being, I'm going to look at making the Chef Infra and Chef InSpec packages defineable/togglable so that we can more easily get ourselves into an appropriate "broken" state to facilitate telling this story. Stay tuned!