At Red Hat Tech Day Netherlands 2026 in Bunnik, Fred van Zwieten and Ismail Dhaoui demoed the new AAP 2.7 Automation Portal, a self-service template gallery where every playbook has a one-click "Start" button. One of the templates shown, "Network - Firewall Remediation," corrects a firewall misconfiguration without the operator needing to know where the playbook lives. Here's a runnable example of what that template can look like under the hood.
Example playbook
---
- name: Network - Firewall Remediation
hosts: firewalls
gather_facts: false
vars:
expected_rule:
name: "block-external-ssh"
action: "deny"
protocol: "tcp"
destination_port: 22
source: "any"
destination_zone: "dmz"
tasks:
- name: Fetch current firewall rules
cisco.asa.asa_facts:
gather_subset:
- config
register: current_config
- name: Check if expected rule is present and correct
ansible.builtin.set_fact:
rule_is_compliant: >-
{{
expected_rule.name in (current_config.ansible_facts.rules | default([]) | map(attribute='name') | list)
and expected_rule.action == (current_config.ansible_facts.rules
| selectattr('name', 'equalto', expected_rule.name)
| map(attribute='action') | first | default(''))
}}
- name: Remediate misconfigured or missing rule
cisco.asa.asa_config:
lines:
- "access-list OUTSIDE_IN extended {{ expected_rule.action }} {{ expected_rule.protocol }} {{ expected_rule.source }} eq {{ expected_rule.destination_port }}"
save: true
when: not rule_is_compliant
register: remediation_result
- name: Log remediation action for audit trail
ansible.builtin.lineinfile:
path: /var/log/ansible/firewall-remediation.log
line: "{{ ansible_date_time.iso8601 }} - {{ inventory_hostname }} - rule '{{ expected_rule.name }}' remediated"
create: true
delegate_to: localhost
when: not rule_is_compliant
- name: Report compliant hosts
ansible.builtin.debug:
msg: "{{ inventory_hostname }} already compliant, no action taken"
when: rule_is_compliant
What it does
The play targets a firewalls inventory group and pulls the running configuration with asa_facts (swap in the collection matching your platform — cisco.ios, arista.eos, or a vendor-specific Ansible Content Collection). It compares the live rule set against expected_rule, a single source of truth for what "correct" looks like. If the rule is missing or its action drifted (for example, someone flipped a deny to a permit), asa_config pushes the corrected line and saves it. Every remediation gets a line in a local audit log before the play reports back.
This mirrors how the Automation Portal template works: the operator clicks "Start," picks a target device or zone from a form, and AAP runs this logic behind the scenes — no manual login to the firewall, no memorizing vendor CLI syntax.
Notes
- Replace
cisco.asa.*modules with the collection appropriate to your firewall vendor; the compliance-check-then-remediate pattern stays the same regardless of platform. - Keep
expected_rulevalues in a group_vars file or, better, source them from a CMDB/ServiceNow lookup so the template stays accurate as policy changes. - Always run with
--check --difffirst against production firewalls, and gate execution behind an AAP job template survey or approval node — a bad "expected" value pushed automatically is worse than the misconfiguration you're fixing. - Pair this template with "Network - Firewall Rule Request" so remediations only happen for drift, not for legitimate approved changes that haven't synced into your source of truth yet.
Takeaway
Wrapping a check-then-fix pattern in a named job template turns firewall remediation into a one-click, auditable action any authorized operator can run — exactly the self-service model AAP 2.7's Automation Portal was built to deliver.
Related Articles
- Ansible Playbook Example: Emergency CVE Patch Rollout
- Ansible Playbook Example: RHEL Patching in a Maintenance Window
- Ansible Playbook Example: Firewall Rule Request Approval Workflow