Never Deploy Broken Playbooks Again: Ansible Automation Platform and Steampunk Spotter Integration

Imagine confidently deploying Ansible Playbooks knowing they’re free of security vulnerabilities and compliance issues. With Steampunk Spotter integrated into Red Hat Ansible Automation Platform (AAP), every job is checked against your company’s policies before and even during execution, and only compliant automation gets to run.

Let’s look at how the integration works and what it brings to your workflow.

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 closes this gap. If an issue is ignored before the playbook runs, or only shows up in the values used at runtime, Spotter stops the job before it reaches your infrastructure.

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 mainly on syntax and style and don’t analyze the actual content used.

This is where Steampunk Spotter shines and adds another layer. It checks the content of your playbooks against your company’s policies, so they’re secure, reliable and compliant, not just well-written. Discover all Spotter features.

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, we fix all identified issues. Even so, Spotter’s checks in the CI pipeline only see the code. They can’t see the values the playbook will use at runtime, and those values can cause serious problems in production.

Insecure 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 Spotter’s built-in checks and your own company policies, 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 makes sure only automation that meets your policies run there, checking it before and during execution. It acts as a “gatekeeper,” catching errors and preventing potentially harmful deployments. This saves you time, prevents risky deployments and keeps execution compliant and secure. As more playbooks are written with the help of AI assistants, this gate holds all of them to the same standard.

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.