Build an AAP Self-Service Template: Firewall Rule Change Approval Workflow

Firewall rule changes are one of the most sensitive and most requested tasks in any network operations queue. Every change needs a business justification, a security sign-off, and a clean audit trail — yet the actual technical work of pushing the rule to a firewall or Cisco/Arista device is often trivial for automation. Red Hat's Ansible Automation Platform (AAP) 2.7 closes that gap with the new Automation Portal, a self-service template gallery that was demoed live by Fred van Zwieten and Ismail Dhaoui at Red Hat Tech Day Netherlands 2026 in Bunnik on 3 June 2026. In this article we focus on one template from that catalog: Network - Firewall Rule Request, which submits a firewall rule change for an approval workflow.

What the Automation Portal Changes

Before AAP 2.7, requesting a firewall change through automation usually meant knowing which job template to launch in the Automation Controller UI, which survey fields to fill in correctly, and which project or inventory it depended on. That's a lot of tribal knowledge for a service desk agent or a junior network engineer to carry.

The Automation Portal flips this around. It presents a curated gallery of self-service templates, each with a single Start button. The requester never needs to know where the underlying playbook lives, which execution environment it runs in, or how its inventory is scoped — they just pick the template, answer a short set of prompts, and submit.

In the Bunnik demo, the catalog included templates spanning several domains:

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

Anatomy of the Firewall Rule Request Template

Conceptually, this template is built from four building blocks that already exist in AAP: a survey, a job template, an approval node in a workflow template, and role-based access to scope who can request and who can approve.

1. The survey. This is what the requester actually sees in the Automation Portal. It should stay short and business-oriented — source, destination, port/protocol, business justification, and a ticket reference are typically enough. Every technical detail (device credentials, target firewall platform, execution environment) stays hidden behind the template.

2. The approval node. In a workflow job template, an Approval node pauses execution and notifies designated approvers — via email, Slack, or ServiceNow depending on how notifications are configured — until someone approves or denies the request, or it times out.

3. The change job. Once approved, the workflow proceeds to the actual Ansible job that pushes the rule to the target firewall or applies it through a network module for the platform in use.

4. RBAC scoping. The Automation Portal only shows templates the logged-in user has execute access to, and only surfaces the approve action to users in the appropriate approval team — so a requester can submit but not self-approve.

Example Workflow Definition

Below is an illustrative workflow job template definition showing how the pieces fit together conceptually. Node names and variable names are illustrative — they show the pattern, not a documented API response from AAP.

---
- name: Network - Firewall Rule Request workflow
  hosts: localhost
  gather_facts: false
  vars:
    fw_source: "{{ survey_source_network }}"
    fw_destination: "{{ survey_destination_network }}"
    fw_port: "{{ survey_port }}"
    fw_protocol: "{{ survey_protocol }}"
    fw_justification: "{{ survey_business_justification }}"
    fw_ticket_ref: "{{ survey_ticket_number }}"

  tasks:
    - name: Log the incoming firewall rule request for audit trail
      ansible.builtin.debug:
        msg: >-
          Rule request {{ fw_ticket_ref }}:
          allow {{ fw_protocol }}/{{ fw_port }}
          from {{ fw_source }} to {{ fw_destination }}
          — justification: {{ fw_justification }}

    - name: Validate requested port is within allowed change range
      ansible.builtin.assert:
        that:
          - fw_port | int >= 1
          - fw_port | int <= 65535
        fail_msg: "Requested port {{ fw_port }} is outside the valid range."

    - name: Apply the approved firewall rule change
      ansible.builtin.include_role:
        name: firewall_rule_apply
      vars:
        rule_action: allow
        rule_source: "{{ fw_source }}"
        rule_destination: "{{ fw_destination }}"
        rule_port: "{{ fw_port }}"
        rule_protocol: "{{ fw_protocol }}"
      when: workflow_approval_status == "approved"

In the actual AAP workflow visualizer, the ansible.builtin.assert validation and the rule-application play would sit in separate nodes connected by an Approval node, so the change job only fires after a human approves the request in the Automation Portal or the Controller UI.

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

Designing the Survey for Self-Service Users

Because the requester in the Automation Portal is often not a network engineer, survey design matters as much as the playbook itself. A few practical guidelines:

• Use plain-language field labels ("Which server or network needs access?") instead of raw variable names.
• Constrain free-text fields wherever possible — dropdowns for protocol (TCP/UDP), regex validation for IP/CIDR fields.
• Make the business justification and ticket reference mandatory fields so the approval node has context to act on.
• Keep the survey to the minimum fields needed for a decision; push everything else (credentials, target device selection logic) into the job template's own variables.

Approval, Auditability, and Least Privilege

The value of routing this through a workflow approval node rather than a "just run it" job template is threefold:

1. Separation of duties — the person requesting the change is never the person approving it, satisfying common change-management and compliance controls.
2. Full audit trail — every request, its survey answers, the approver's identity, and the timestamp of approval or denial are recorded in the AAP job history.
3. Consistent execution — because the actual firewall push always runs through the same job template and execution environment, there's no risk of an engineer running an ad hoc, unreviewed script against production firewalls.

Key Takeaways

• AAP 2.7's Automation Portal gives operators a one-click, self-service gallery of templates — no need to know where a playbook lives or how to configure it.
• The Network - Firewall Rule Request template pairs a business-friendly survey with a workflow approval node, so firewall changes go through a human sign-off before execution.
• A well-designed survey keeps technical complexity out of the requester's view while still capturing everything the approver and the audit trail need.
• Approval nodes, RBAC scoping, and consistent execution environments together deliver separation of duties and a clean compliance story for network change management.
• This template complements Network - Firewall Remediation and Network - Backup Switch Configs, forming a broader network change-management set inside the same self-service catalog shown at Red Hat Tech Day Netherlands 2026.