Imagine confidently deploying Ansible Playbooks knowing they’re free of security vulnerabilities and compliance issues. The integration of Steampunk Spotter with Red Hat Ansible Automation Platform (AAP) ensures that every job can be inspected for security vulnerabilities and compliance issues before and even during execution. Let’s delve into how this integration streamlines your workflow and guarantees flawless playbooks.

Why Integrate Ansible Automation Platform with Steampunk Spotter?

Before diving into the specifics, let’s explore why these powerful platforms work best together. While code checking tools help us validate Ansible Playbooks before execution which significantly shortens debugging time and prevents major production issues, the truth is that static code analysis and early fail principle still fall short.

Found errors can be intentionally or unintentionally bypassed. And even if all identified errors are fixed before execution, there’s no guarantee of reliable and secure outcomes when running playbooks in AAP because static code analysis can’t assess the values used within the playbook itself. And these values can present significant security risks, even if the playbook itself passes static code analysis. That’s why it’s important to also check the playbook while it’s being executed.

Steampunk Spotter bridges this gap, ensuring playbooks are thoroughly tested before and during execution to help you improve Ansible Playbook quality, reduce playbook errors, mitigate security risks, ensure playbook compliance, and achieve secure execution.

The Traditional Way: Develop, Test, and Execute Ansible Playbooks

We typically start by creating a YAML file and writing the playbook code. Ansible Lint or other similar linting tools help catch common syntax issues during this stage. However, linters focus solely on syntax: they check only for style errors and don’t analyze the actual content used.

This is where Steampunk Spotter shines. This powerful Ansible Playbook Platform analyzes the content of your playbooks, ensuring they’re not just syntactically correct, but also secure, reliable, and compliant with your company policies.

Let’s consider an example.

---
- hosts: all
  connection: network cli
  gather_facts: false

  tasks:
    - name: Create security group.
      amazon.aws.ec2_security_group:
        name: "web-app-sec"
        description: "Sec group for app web-app"
        region: "eu-west-3"
        access_key: "124gfsd23rwddsf2"
        rules:
          - proto:tcp
            from_port: 22
            to_port: 22
            cidr_ip: 0.0.0.0/0
          - proto: tcp
            to_port: 80
            cidr_ip: 0.0.0.0/0
      register: result_sec_group

    - name: EC2 instance create.
      amazon.aws.ec2_instance:
        name: "VM_for_demo"
        vpc_subnet_id: subnet-5calable
        key_name: "prod-ssh-key"
        security_group: "web-app-sec"
        volumes:
          - device_name: /dev/sdal
            ebs:
              volume_size: 64
              delete_on_termination: true
        image_id: ami-08c947c038321a605
        network:
          assign_public_ip: true
        tags:
          demo: VM

    - name: Gather information about the instance with a tag.
      amazon.aws.ec2_instance_info:
        filters:
          "tag: demo": VM
      register: instance_id

    - name: Test
      amazon.aws.ec2_snapshot:
        instance_id: "{{ instance_id }}"
        device_name: /dev/sda1
        description: snapshot of /data from VM_for_demo

    - name: VPC info.
      steampunk.aws.ec2_vpc_info:
        auth:
          access_key: dafsgdhzjthtrereddscfr
          secret_key: "{{ my_secret_key }}"
          region: "{{ my_region }}"
      register: vpcs

    - name: Create a new database with name "acme".
      community.postgresql.postgresql_db:
        db: acme

    - name: For passing JSON, etc.
      community.postgresql.postgresql_query:
        query: INSERT INTO test_table (array_column) VALUES (%s)
        positional_args:
        - '{1,2,3}'

    - name: Ensure that the desired snmp strings are present.
      cisco.ios.ios.config:
        lines:
          - snmp-server community ansible-public RO
          - reboot

This seemingly correct playbook passed the syntax check, but it is clear that it includes security issues that would cause major problems.

As we see, the playbook is written correctly, looks fine, and is in line with Ansible best practices, but it contains security and compliance issues that regular linters wouldn’t catch.

So, the next step usually is to scan the playbook locally. We commit the code to a Git repo which in our case includes CI pipelines in place that check the quality of code – we have Ansible Lint and Steampunk Spotter in place to safeguard our main repo.

First, we scanned our playbook with Ansible Lint:

Then Spotter provided us with some significant security issues:

Clearly there is a difference in the output. But even if Spotter provided deep insights into security issues, there’s a chance users might choose to ignore them to save time.

Businesses can block a merge request to prevent the playbook from passing the CI pipeline, but users can just leave the code as it is in their branch and deploy the code with potential risks in the Ansible Automation Platform.

Or, more commonly, this scenario: we correct all identified issues, but Spotter, while providing deep insight into the quality and security of playbooks and static analysis of not only Ansible content, but also Ansible modules and the code itself, still doesn’t have access to the values used in them, and these can be a big problem during production.

Unsecure Playbooks: Two Scenarios to Consider

No matter what the reason, we are left with a playbook that contains quite harmful security issues, so if we run it in AAP, here’s how this plays out with and without Spotter integration:

Without Spotter Integration:

• The user syncs the project, retrieves playbooks, sets execution environments, and provides necessary credentials.
• They launch the playbook, effectively deploying code with potential security issues due to ignored tests and feedback from Steampunk Spotter and Ansible Lint.

With Spotter integration

Similar steps occur initially, but Steampunk Spotter becomes the game-changer. Users can still skip checks, but the key difference lies in selecting the execution environment within the job template. (We’ll explain this further.)

When the user launches the job template, Steampunk Spotter detects potential security issues before and during execution. Spotter checks the values of parameters and stops execution if they violate your internal policies. In our example, Spotter would flag the playbook with errors, preventing its execution and potential security breaches.

Steampunk Spotter and AAP Integration 101

We’ve explored the need for this integration and its benefits. Now, let’s see how it works and what new it brings to the table in the Ansible automation world.

The integration requires custom Execution Environments (EE) to be used on Ansible Automation Platform, which are simple to create, and our Steampunk experts provide all the necessary instructions and support. Spotter also comes with existing tooling to save you time on creating new execution environments.

With the new execution environment containing Spotter, you can set it up within AAP and enforce its use for all users. This ensures all job templates undergo the necessary validation and inspection before execution.

What You Need to Change: A Streamlined Process

• Update your execution environments.
• Add custom credentials.
• That’s it! It’s a quick and efficient process that delivers immediate results.

Runtime Checks with Steampunk Spotter: A Game-changer

Traditionally, we’ve relied on various methods to check code before execution, followed by additional scans. This approach, known as the “early fail principle,” is beneficial for catching errors early on. However, it has limitations. Static code analysis can only check Ansible tasks, parameters, and predefined values but struggles with variables and dynamic values produced during task execution. This is where runtime checks, also known as dynamic analysis, come in.

Runtime checks offer valuable insights into these dynamic values during playbook execution. Based on pre-defined checks and policies within Steampunk Spotter, they can halt execution if potential problems arise. While this might be considered a “late fail,” it’s certainly better to catch issues before they impact your infrastructure.

Let’s explore a couple of scenarios:

• Imagine a playbook deploying a Samba server with specific configurations. The playbook might attempt to open ports, including port 22 (SSH), to a public IP address, which could violate your company’s security policy. Static code analysis wouldn’t identify this risk since the port number is provided as a variable.

With runtime checks, however, Spotter detects this issue during execution and stops the playbook, preventing a potential security breach.

• Another example involves creating a user with the username and password set to “ADMIN.” While Ansible might allow this seemingly valid password, it might contradict your company’s policy against weak passwords.

Spotter’s runtime checks would prevent this by identifying the weak password and halting execution before compromising security.

Now we saw that Spotter stopped Ansible during execution, and with that prevented a security issue on our infrastructure. But that’s not the end yet. Execution stopped, but we can’t see the code on which the error was triggered that would enable us to see what the actual problem was and what we have to fix.

Again, Spotter has you covered.

Beyond Stopping Execution: Code Analysis

While stopping execution is crucial, Steampunk Spotter offers additional benefits. If Spotter halts execution due to an issue, you can access the Spotter App to analyze the specific code causing the problem. This allows you to easily share the problematic code with your team and work together to fix it.

The Scan environment feature captures a snapshot of relevant information during each scan, including Ansible and Python versions, installed collections, and Ansible configuration overrides. This provides valuable context for troubleshooting any issues identified by Spotter.

Summary

Red Hat Ansible Automation Platform focuses on running your automation efficiently and Steampunk Spotter validates your Ansible content before and during execution in AAP. It acts as a “gatekeeper,” catching errors and preventing potentially harmful deployments. This ensures thorough testing throughout the Ansible workflow, saving you time by preventing risky deployments and achieving compliant, secure execution.

Beyond identifying issues, Steampunk Spotter empowers collaboration through code rendering and provides valuable insights through the scan environment feature.

Don’t miss the opportunity to streamline and safeguard your Ansible workflows. Get a live demo today to see the power of Steampunk Spotter and AAP integration in action.