Build an AAP Self-Service Template: Firewall Misconfiguration Remediation

Firewall misconfigurations are one of the most common causes of unplanned outages and failed audits — a stale ACL entry, an overly permissive rule, or a drifted object group can sit unnoticed for months until it blocks legitimate traffic or, worse, allows traffic it shouldn't. At Red Hat Tech Day Netherlands 2026 in Bunnik, Fred van Zwieten and Ismail Dhaoui demoed how Ansible Automation Platform 2.7's new Automation Portal turns this exact problem into a one-click self-service experience with the "Network - Firewall Remediation" template.

This article walks through what that template does, why it belongs in a self-service catalog, and how to structure the underlying job template and playbook so operators — not just automation engineers — can safely trigger a fix.

Why Firewall Remediation Belongs in the Self-Service Gallery

The Automation Portal shown in the AAP 2.7 demo is a curated gallery of job templates, each exposed behind a single "Start" button. The point is to remove two barriers that normally keep automation locked away from the people who need it most:

• Operators don't need to know where the playbook lives. No SSH access, no Git repository to clone, no execution environment to configure.
• Operators don't need to know how to configure it. Survey prompts collect only the inputs that matter — the device, the rule identifier, the remediation action — and AAP handles credentials, inventory, and execution environment selection behind the scenes.

See also: Build an AAP Self-Service Template: Backup Network Switch Configs to Git

What the Template Does

At a conceptual level, "Network - Firewall Remediation" performs a targeted, auditable correction rather than a full configuration push:

1. Take a target device (or a small set of devices) and a description of the misconfigured object — an ACL entry, NAT rule, or object-group member.
2. Back up the current running configuration before touching anything (the same backup logic that powers the "Network - Backup Switch Configs" template can be reused here).
3. Apply the corrective change idempotently, using vendor-specific network collections rather than raw CLI strings.
4. Validate the change against the intended state and report success/failure back through the job output.

Comparing the Firewall-Focused Templates

The catalog shown in the demo deliberately splits firewall-related work into three distinct templates, each with a different risk profile and audience:

Building the Job Template

In AAP, the self-service entry is just a job template with a friendly name, an icon, and a survey — the Automation Portal gallery is a presentation layer on top of standard job templates and workflow templates you already manage in the controller. A minimal setup looks like this:

• Name: Network - Firewall Remediation
• Inventory: your network device inventory (grouped by vendor, e.g., cisco_ios, arista_eos)
• Credentials: a machine credential scoped to network device access, injected automatically — the operator never sees it
• Execution Environment: one that includes cisco.ios, arista.eos, or your relevant network collection
• Survey: prompts for device_hostname, rule_id or object_group, and remediation_action (e.g., remove, correct-cidr, disable)

---
- name: Network - Firewall Remediation
  hosts: "{{ device_hostname }}"
  gather_facts: false
  connection: network_cli

  vars:
    remediation_action: "{{ remediation_action | default('correct-cidr') }}"

  tasks:
    - name: Back up running configuration before remediation
      cisco.ios.ios_config:
        backup: true
        backup_options:
          dir_path: "/tmp/backups/{{ device_hostname }}"

    - name: Show current ACL entry for the affected rule
      cisco.ios.ios_command:
        commands:
          - "show access-lists {{ acl_name }} | include {{ rule_id }}"
      register: current_rule

    - name: Correct the misconfigured ACL entry
      cisco.ios.ios_config:
        lines:
          - "no {{ rule_id }}"
          - "{{ corrected_rule_line }}"
        parents: "ip access-list extended {{ acl_name }}"
      when: remediation_action == 'correct-cidr'

    - name: Remove an overly permissive or stale rule
      cisco.ios.ios_config:
        lines:
          - "no {{ rule_id }}"
        parents: "ip access-list extended {{ acl_name }}"
      when: remediation_action == 'remove'

    - name: Validate the corrected ACL entry
      cisco.ios.ios_command:
        commands:
          - "show access-lists {{ acl_name }} | include {{ corrected_rule_line }}"
      register: validation
      when: remediation_action == 'correct-cidr'

    - name: Fail the job if validation did not find the expected rule
      ansible.builtin.fail:
        msg: "Remediation did not apply as expected on {{ device_hostname }}"
      when:
        - remediation_action == 'correct-cidr'
        - corrected_rule_line not in (validation.stdout | join(''))

This structure keeps every remediation run backed up, targeted, and self-validating — three properties that matter a lot more once the "Start" button is available to anyone with catalog access, not just the network team.

See also: Build an AAP Self-Service Template: Branch Network Health Check

Guardrails Worth Adding

A self-service firewall template is only as safe as the guardrails around it. Worth layering on top of the base job template:

• Job template permissions scoped to the NOC/help-desk team via RBAC, not the whole organization.
• Survey field validation (regex on rule_id, restricted choice lists for remediation_action) so free-text input can't turn into an arbitrary config push.
• Notifications on job completion/failure routed to the network team's chat channel, so remediation actions triggered by non-engineers are still visible to the people who own the firewall estate.
• Change ticket linkage — even without a full approval workflow, tie the job's launch to a ticket number captured in the survey for audit trails.

Key Takeaways

• The Automation Portal's "Network - Firewall Remediation" template, demoed at Red Hat Tech Day Netherlands 2026, gives non-specialist operators a one-click way to fix a known firewall misconfiguration without touching a playbook or credential directly.
• It's deliberately scoped narrower than "Network - Firewall Rule Request" — remediation corrects an existing problem, while new rule requests go through an approval workflow.
• Under the hood it's still a standard AAP job template: inventory, scoped credentials, a purpose-built execution environment, and a tight survey.
• Backing up the running configuration before every remediation run, and validating the result afterward, is what makes it safe to hand this button to people outside the automation team.
• RBAC-scoped access, survey validation, and notifications are the guardrails that turn a convenient template into a trustworthy one.