Besides helping ensure compliance with regulatory standards, InSpec is a great solution for detecting compliance with your organization’s own rules and expectations. Our friends at Jack Henry & Associates Inc. recently detected and corrected an issue in their environment thanks to the power of InSpec and Chef Automate.
Jack Henry provides IT services to over 9000 banks, primarily community banks and credit unions. Seth Thoenen, a Systems Engineer at Jack Henry & Associates Inc., shares his story with us in this guest blog post.
At Jack Henry & Associates Inc. we are just beginning our journey of rolling out Chef to the company. We started by deploying Chef to 300 nodes in two of our many environments which, in turn, runs the audit cookbook. The audit cookbook is executing a small InSpec profile to test compliance for some of the agents we deploy to our environments, among other things. One day I logged into our Chef Automate instance to check how compliance was looking across the nodes we had bootstrapped. The compliance graph looked like this:
If you’ve never seen the Chef Automate compliance graphs before, the orange line indicates the number of nodes that are not compliant with their assigned profiles, while the blue indicates compliant nodes. After diving into the data, we found that all the nodes in one of our environments were out of compliance across the board because one of our agents wasn’t receiving its updates. Because updates are logged to a text file on the local machine daily, we can use the InSpec powershell resource to test whether a machine has been updated recently:
describe powershell('(New-TimeSpan -Start (get-item c:\path\to\myfile.txt).lastwritetime -end (get-date)).Days') do
its('strip') { should cmp 0 }
end
At the time, there were no configuration changes pushed to this environment that would lead to so many nodes drifting out of compliance in such an aggressive manner. After investigating the issue with our colleagues responsible for the agent, we found the repository for this environment failed to provide updates to its clients. This was a true compliance failure. Once the problem was resolved, our nodes became compliant:
Naturally, we should be using InSpec to validate the configurations we put in place with Chef. However, the moral of this story is: write InSpec profiles for everything that your business cares about even if the item is not under Chef’s control. This communication failure between an agent and its local repository wouldn’t have been easily solved with Chef, but InSpec and Chef Automate were key to detecting the failure and correcting it.
We are just getting started with rolling out Chef to all our environments, and we have more use cases for InSpec that we have yet to implement. Harnessing the power of InSpec and Chef Automate will allow us to do some really awesome things in the future that would have been impossible before.