Spotter Custom Policies 101: A Beginner’s Guide to Tailored Automation Checks

Automation workflows often come with unique requirements that standard rules can’t always address. That’s where custom policies in Steampunk Spotter step in. Leveraging Open Policy Agent (OPA) integration, Spotter empowers users to design tailored policies that enhance automation quality, security, and compliance.

This blog post will introduce custom policies, why they matter, and walk you through creating your first custom policy in Spotter.

A Story of Automation Excellence: Meet Sarah

Sarah, a security compliance officer at a global enterprise, was tasked with auditing logs and preventing misconfigurations across the company’s infrastructure. One of Sarah’s focus areas was ensuring Ansible playbooks adhered to strict compliance and security standards. While the company used tools with pre-built checks, they weren’t sufficient to address the specific compliance needs of Sarah’s organization. When Ben discovered the power of custom policies in Steampunk Spotter , their workflow transformed.

This series follows Sarah’s journey as they harness the potential of custom policies to tackle misconfigurations and compliance challenges head-on.

What Are Custom Policies in Spotter?

Custom policies are user-defined rules that allow you to evaluate your Ansible playbooks against your organization’s specific standards. These policies complement Spotter’s pre-built checks, giving you the flexibility to ensure compliance, security, or best practices unique to your environment.

Why Use Custom Policies?

1. Tailored Compliance: Ensure playbooks meet internal or industry-specific guidelines.

2. Enhanced Security: Mitigate risks by codifying security policies.

3. Automation Best Practices: Define and enforce standards for optimal automation workflows.

4. Scalability: Apply consistent policies across teams and projects.

5. Multi-Project Management: Define and enforce policies specific to different projects or organizations directly within the Spotter app.

How Custom Policies Work

Spotter integrates Open Policy Agent (OPA) , a high-performance policy engine, to enforce these rules. Custom policies are written in Rego , a declarative language for defining policy logic. Once uploaded to Spotter, these policies can be applied across different projects or organizations to evaluate your playbooks during scans.

Example: Hello World in Rego Files

A minimal example of a custom policy written in Rego to be used in Spotter:

package hello_world

MyFirstRule[result] {
    result := {
        "check_type": "OTHER",
        "message": "Hello world - printed for every scan and exactly once."
    }
}

• The package keyword is mandatory in Rego and defines a namespace.

• The rule MyFirstRule contains the policy logic and outputs a message for Spotter to display.

• The check_type can be OTHER, PLAY, TASK, or VARIABLE, and its presence is crucial to ensure the user receives feedback pinpointing where the error occurs in the file.

Step-by-Step: Writing Your First Custom Policy

Sarah’s first challenge was preventing hardcoded AWS access keys in playbooks. With Spotter’s custom policy feature, they crafted a solution:

1. Understand the Requirements

Define what you want the policy to achieve (e.g., disallow hardcoded secrets in playbooks).

2. Get Input from Spotter

Before writing your custom policy, export the payload from Spotter to understand the structure of your playbook input:

spotter scan playbook.yml --export-payload payload.json 

This generates a JSON representation of your playbook, which serves as the input for your custom Rego policies.

3. Write the Policy in Rego

Example: Detect plaintext AWS access keys.

package Spotter

SpotterPolicy[result] {
         task := input.tasks[i] ## Get Spotter's input, then narrow it down to task level.
         task_args := task.task_args["amazon.aws.ec2_security_group"].access_key 
         regex.match("{{.*}}", task_args) == false

         result := {
             "correlation_id": task.task_id, ## Here, we must include task_id, so Spotter knows on which tasks the rule was triggered.
             "check_type": "TASK",
             "subcode": "PlainText_Variable", ## Subcode is a parameter that is optional, and it's used to then skip or enforce specific rules.
             "message": "Access key should be written as a variable, not plain text!" ## Message to the user when the rule is triggered.
         }
}

4. Upload the Policy to Spotter

Navigate to the Custom Policies section in the Spotter App and upload the .rego file.

Then click Add new policy and copy-paste the policy in Step 3.

Don’t forget to save it.

Alternatively, use the CLI:

spotter policies set policy.rego

5. Run a Spotter Scan

Run a Spotter scan:

spotter scan playbook.yml

6. Analyze the Results

Spotter will highlight violations and provide actionable insights.

Best Practices for Creating Custom Policies

Sarah learned several best practices as they honed their skills with Spotter:

• Modularity: Write small, focused policies for better maintainability.

• Documentation: Include comments in Rego files for clarity.

• Testing: Validate policies with various playbook scenarios.

• Collaboration: Share policies across teams to promote standardization.

Conclusion

By embracing custom policies in Steampunk Spotter, Sarah transformed their workflow and enhanced their organization’s playbook quality. This is just the beginning of Sarah’s journey—next time, we’ll explore how they tackled complex compliance challenges using advanced policy techniques, specifically how to check for potentially sensitive data leakage over all Ansible-related content.

Stay tuned for the next post in this series as Sarah’s automation adventure continues!