July 21, 2021
We have recently launched two awesome features (in what feels like no time at all) and with each adding unique value, we thought it would be beneficial to explore these features with a bit more depth.
I can still remember (even before officially starting my role with the company only a few months ago) fondly chatting about our next big ideas. One of these big ideas and visions of the engineering team were that they wanted to deliver remediation. There is of course the plugin for vRealize Orchestrator but not every one deploys this or has the skills to use it to the best of their advantage. One of the key things we wanted to deliver was an ease of use operation and trying our best to not limit our tools to a single set where possible. Even in this first release of the feature set we have seen the ability to use PowerCLI and Ansible. I am sure as time progresses we will see other tools added along with options that can best fit your needs.
A great example of this, and one I see often in environments, is that SSH is running on a host. As you can see in the screenshot below, the little purple R means that we have found a failure and we can use remediation to fix this.
Before we get into how some of this works, we need to take a small step back and explain some of the basics again, as these are key to how we are able to be so agile in crafting these remediation capabilities to suit your specific needs
When Runecast Analyzer does its scan, part of that magic is it performing a series of checks. From the data we parse the values (and normally these checks are part of what we call a sentence) to ensure that specific criteria are met. I have tried to illustrate this below.
You can see this from within the findings below, it returns the hosts and the states of the service if it matches the above checks.
The great thing about this now is that we have a solid set of building blocks that our engineers can work from. What we can do with this is create remediation plans based on the checks within the sentence and build them up from the objects matched from each check. This then allows us to ensure that the actions are also only run against the affected properties, as in some other examples you may find a service is started on 4 hosts but the policy may only be set on three. When the script is created in the back end, the actions to remediate these will only be run against the affected values we have analyzed against.
So what we now need to do is start that magic in the Generate Script section. This makes a call to the backend and it displays the results on screen much like the findings tab. One part of this process I like at present is that the user needs to download the script or copy and paste this before running actions. This ensures that there is a final step of validate, or from my experience it makes it very easy to place this into a change record to explain what you will be doing. This in turn creates excellent evidence for any auditors, and you can keep tabs on this or any drift as this will appear again in the findings.
The other part of architecting this the way we did is that it means we can also build on these remediable actions in the same way we deliver our knowledge updates. I know the team is working hard to add more to the current actions, and with new standards being updated/released this paves such a good way to show return on investment, as you can swiftly take action against any risks found within your environment.
Please Note: For the most up-to-date information on Runecast Analyzer’s Configuration Vault capabilities, check out the Runecast Analyzer User Guide.
I hope this helps uncover some of the way this starts to work and we hope to follow up with further articles showing all the different technologies this can work for. Is there anything you want to see this do or some specific tooling you may want to utilise with the results? Help us with a quick survey here or contact us if you would like follow-up to a specific point.
Our customers and partners tell us that, once they tried Runecast Analyzer, they couldn’t afford NOT to use it in their tech stack.