Steampunk Spotter, an Ansible Playbook scanning tool, includes a variety of checks that improve the quality, reliability, and security of your Ansible Playbooks. The checks are divided into several categories:

Best practice checks

Best practice checks help you write playbooks that keep a common standard and aim to be more consistent, reliable, and readable. They also support the Red Hat Ansible Best Practice guide:

• Check for fully qualified collection names (FQCN) and automatically apply rewrites.

• Check for inline parameters and get suggestions for simpler rewrites.

• Check if the file mode is set and configured correctly.

• Check if modules are certified.

• Check for Ansible requirements file (requirements.yml), version mismatch, and missing collections.

Validation checks

Validation checks perform validation of your use of modules, parameters, and parameter values within playbooks to prevent misconfigurations during the development:

• Check if parameters are deprecated, required, or unknown.

• Check for specific conditions depending on parameter values.

• Check for missing arguments, reserved variables, and default value changes.

• Check the stdout callback. 

• Check for short names with alternatives. 

• Check for callback with FQCN. 

Content upgrade-related checks

They allow you to perform validation on arbitrary versions of Ansible and Ansible Collections, ensuring your playbooks are always supported with target versions. These checks are also used to support upgrades of Ansible Playbooks and help you keep them up to date:

• Check for removal or renaming of modules, and removal, or deprecation of parameters.

• Check for allowed value changes and default parameter value changes.

• Checks are based on publicly available Ansible Porting Guides. You no longer have to follow all the necessary changes in Ansible as Spotter automatically warns you about them.

Spotter ensures you always keep up to date with the progress of Ansible, facilitating upgrades of the Ansible core engine and Red Hat Ansible Automation Platform. 

Short-term roadmap checks

Our team is constantly working hard on adding new checks, and the checks below are at the top of our priority list for the very near future. Additional content upgrade-related checks and custom policies will be rolled out in mid-April; the security-related checks are coming your way in mid-May. See what exciting new checks we have planned for you:

Content upgrade-related checks

• Get warnings about deprecated modules/collections in upcoming Ansible versions.

• Get warnings for changes in default values for upcoming versions of Ansible.

• Check the defined connection option. 

• Define the required Python version for a specific Ansible version. 

• Get warnings about changes in return values in different Ansible versions. 

• Get hints to update the Python interpreter.

• Generate and maintain requirements.txt file for the necessary Python modules. 

Security checks

They will be used to prevent security vulnerabilities in code infrastructure and ensure the secure execution of automation. They will help you proactively evaluate runtime security threats and prevent security breaches. They will allow you to follow the industry’s security best practices, and not only that, but you will also be able to define your internal security team standards.

Spotter considers the security of Ansible Playbooks in two areas: 

• Static analysis of playbooks considering security best practices provided by vendors, such as cloud providers. 

• Dynamic analysis of Ansible modules that are implementing access to services.

Custom rules and policies

Soon, you will be able to define your very own custom rules and policies. You will be able to configure your specific requirements and use cases, which will allow you to enhance the security of your playbooks the way you envisioned it. This includes defining new corporate policies and further specifying Ansible playbook standards to achieve highly customizable automation:

• Specify modules/collections that are allowed.

• Define specific naming conventions.

• Limit required values on specific modules and entities (exposed ports, VM size, and so on). 

• Have custom security rules, for example, to comply with Center for Internet Security (CIS) or Health Insurance Portability and Accountability Act (HIPAA) standards. 

Because the custom rules and policy support will be based on Open Policy Agent (OPA), existing OPA-based policies may be included in Spotter with minimum additional effort.

Full Steam(punk) Ahead

At Steampunk Spotter we are entirely dedicated to creating a seamless user experience. We assess every feature from your perspective and then use our extensive expertise to design it in an applicable and functional way. Our checks are no different. They are designed to benefit you in every way; achieve secure and reliable automation, the Spotter way!

We invite you to try Spotter for yourselves, you can register for free here.

And if you are a user already, let us know what you think, here. All feedback is warmly welcomed and appreciated.