Steampunk Spotter: Skipping and Enforcing Checks

This blog post will delve into Spotter’s practical feature of Skipping and Enforcing Checks.

Understanding the Skipping and Enforcing Checks feature

The skipping and enforcing checks feature allows you to fine-tune Spotter’s output, enabling the execution of checks that align with specific use cases. For example, if Spotter finds a potential risk, which you assess and accept, you can decide to skip it and Spotter won’t show you the error, hint, or warning again. And if you are leading a team and want to be sure a certain check is always included, you can enforce it on the administrative level. With Spotter, you’re always in control. This functionality offers centralized control over Ansible Playbook checks, determining which checks to skip and which to enforce throughout automation workflows.

Levels of control

This feature operates at three distinct levels: organization, scan, and task.

Organization level

At the highest level, organization administrators can upload a JSON or YAML configuration file via Spotter SaaS. The default organization will be used if none is specified. This configuration file defines checks to be skipped and enforced, and the configuration then impacts scans carried out within the organization.

The parameters for skipping/enforcing checks include event codes, subevent codes, and fully qualified collection names.

• event: The code or name of the check result.  

• subevent_code: Check subcode. 

• fqcn: A fully qualified collection name.  

Example of a JSON configuration file:

Here, you can see that checks with codes H2200 and E005 are skipped, but the latter will only be skipped for tasks using sensu.sensu_go.user Ansible module. On the other hand, we want to ensure that we always use fully qualified collection names, check E903 for anyone scanning within your organization is enforced.  

You can then use the config set command to upload it to your organization.

After that, you can use the config get command to display the current configuration for a particular organization to verify that your configuration is correct.  

If you or the organization admin want to clear the current organization configuration, it is possible to use the config clear command. 

Scan level

On the scan level, developers can create a configuration file named .spotter.yml that needs to be in the current project of the playbook. The file dictates which checks are ignored or enforced for that particular scan. This level of control is particularly valuable for solo projects with unique requirements.

Example of a .spotter.yml file:

Here, more checks are ignored – E903, W2603*, and H1900, but just for the sensu.sensu_go.user module. A security check W2600 with subcode B411 originating from Bandit, a tool designed to find common security issues in Python code, is also ignored and only for the inwx.collection.dns module. On the contrary, W2600 with subcode B411 for community.aws.data_pipeline module is enforced.  

Task level

At the task level, skipping checks is achieved by adding #noqa YAML comments at the end of relevant lines within Ansible tasks. This approach allows for selective check-skipping within specific tasks. An optional parameter can also target specific, fully qualified collection names for even more granular control.

Example of #noqa YAML comments in a playbook:

In this example, W003, E903, and W1800 are ignored on the second task; on the third task, H1900 and specify the community.crypto.x509_certificate FQCN in the square brackets. This is an optional parameter that applies the skipping to only that FQCN. This is not especially important for tasks, but it will be helpful when ignoring in blocks, plays, or whole playbooks. In the last task, H2606 and W2600 are ignored; the subcode and FQCN optional parameters are specified here.  

Putting it into practice

To illustrate, we have a sample Ansible Playbook here to use. This playbook comprises tasks involving Ansible collections like sensu.sensu_go, ansible.builtin, and community.crypto. Using the examples above, we will scan the playbook, using each level of skipping and enforcing checks.

- name: Sample playbook  
  hosts: localhost  
  tasks:  

    - name: Create a new Sensu Go user  
      sensu.sensu_go.user:  
        password: "{{ lookup('env', 'SENSU_USER_PASSWORD') }}"  
      when: true 

    - name: Get the payload from the API 
      uri:  
        url: "/some-url" 
        method: GET  
        user: "username1"  

    - name: Ensure that the server certificate belongs to the specified private key  
      community.crypto.x509_certificate:  
       path: "{{ config_path }}/certificates/server.crt"  
       privatekey_path: "{{ config_path }}/certificates/server.key"  
       provider: assertonly  

    - name: Create an example.com A record with value 127.0.0.1  
      inwx.collection.dns:  
        domain: example.com  
        type: A  
        value: 127.0.0.1  
        username: test_user  
        password: test_password  

    - name: Create AWS data pipeline  
      community.aws.data_pipeline:  
        name: test-dp  
        region: us-west-2  
        objects: "{{pipelineObjects}}"  
        parameters: "{{pipelineParameters}}" 
        values: "{{pipelineValues}}"  
        tags:  
          key1: val1  
          key2: val2  
        state: present  

First, let’s scan the playbook using the full profile ( read blog on Spotter profiles ) and no check refinements.

Now, let’s apply the organization-level configuration file.

We see that we have 1 error and 1 hint less because we skipped two checks that matched our organization configuration.  

Now, let’s scan using the scan level .spotter.yml. file.

Many warnings are gone, but we could not ignore E903 on the scan level because it is enforced on the organization level. 

And the final level, task level scan:

We are only left with 2 errors, 1 warning, and 5 hints. Again, we have been unable to skip E903 on the task level because it is enforced on the organization level. We also couldn’t skip W2600 with subcode B411 for community.aws.data_pipeline module because we enforced it on the scan level before.  

A Versatile Solution: Flexible Ansible Playbook scanning

As demonstrated, Spotter’s Skipping and Enforcing Checks feature can be harnessed to improve efficiency and relevance in scan results. You can strategically skip or enforce checks based on the context of their automation tasks by using organization, scan, and task-level configurations.

This powerful feature allows for centralized management of checks and helps maintain consistent standards organization-wide. Its three-level approach provides unmatched customization, adapting checks to specific needs, enhancing workflow efficiency, and resonating with businesses in search of adaptable, user-empowering, and forward-thinking automation solutions.

Curious to explore the potential of Spotter? Try Steampunk Spotter and embark on your journey towards reliable, efficient, and secure automation.

Interested in Spotter, but don’t know how to start? Explore our Getting started guide.