The integration of Ansible into the management of Cisco Adaptive Security Appliances (ASA) represents a paradigm shift from manual, command-line interface (CLI) driven administration to a scalable, infrastructure-as-code (IaC) model. By leveraging Ansible's agentless architecture, network engineers can automate the deployment of security policies, the installation of REST API images, and the synchronization of configurations across multiple firewall instances. This transition is critical for maintaining consistency across complex network topologies where manual entry is prone to human error. The capability to treat network configurations as version-controlled code allows for rapid deployment, easier auditing, and the ability to recover from configuration drifts with minimal downtime.

Architectural Foundations of Ansible for Cisco ASA

Ansible operates by utilizing a push-based model, meaning it does not require an agent to be installed on the target Cisco ASA device. Instead, it leverages existing management protocols to execute commands. For the Cisco ASA, this typically involves the network_cli connection type, which emulates a terminal session via Secure Shell (SSH). This mechanism is vital because it allows the administrator to manage the device exactly as they would through a physical console or a remote terminal, but with the programmatic precision of a YAML-based playbook.

One of the most significant advantages of this approach is that it removes the prerequisite for advanced API activations or the presence of a Cisco Firepower Management Center (FMC). Because Ansible emulates the CLI, it can interact with the ASA's operating system directly. This means that even in legacy environments or specific hardware models like the ASA 5506, automation can be achieved without the overhead of configuring the REST API or the ASDM (Adaptive Security Device Manager).

Technical Specifications and Hardware Compatibility

When deploying Ansible against Cisco hardware, understanding the specific software version and hardware module is paramount to ensure compatibility with the Ansible modules being used.

The ASA 5506, running version 9.9(2), serves as a baseline for these operations. The presence of the FirePOWER Services Software Module indicates a hybrid environment where the ASA handles the stateful inspection and routing, while the FirePOWER module provides advanced threat protection. However, it is important to note that while the ASA OS itself can be managed via Ansible's CLI emulation, the SFR (FirePOWER) module possesses different management requirements. To configure the SFR module, the device must be registered to a Firepower Management Center (FMC), which can then be managed via Ansible. Alternatively, migrating the hardware to FirePOWER Threat Defense (FTD) would allow the use of FTD-specific Ansible modules, provided the FTD REST API is activated.

Infrastructure Setup and Ansible Host Configuration

The foundation of any automation project is the control node. For an ASA deployment, a Linux workstation is required. A common professional setup involves using a CentOS Linux release 8.1.1911 (Core) virtual machine. This environment provides the necessary stability and package management to host the Ansible client and the associated Python libraries required for network communication.

The development process follows a strict logical sequence to ensure the environment is stable before production deployment:

1. Build the Ansible Host: Install the core Ansible package and any required dependencies on the Linux VM.
2. Configure Inventory: Define the target devices and the necessary connection variables.
3. Build YAML Ansible-Playbook: Author the specific tasks to be executed on the firewalls.
4. Run the Ansible-Playbook: Execute the automation against the target environment.

Inventory Management and Variable Definition

The inventory file, often named INV.INI, serves as the source of truth for the Ansible control node. It maps the logical groups of devices to their physical IP addresses and defines the specific variables required to authenticate and communicate with the Cisco ASA.

In a professional environment, the inventory is divided into groups and variable sections. For instance, the [firewalls] group contains the IP addresses of the target devices, while the [firewalls:vars] section contains the connection parameters.

The necessary variables for a successful ASA connection include:

• ansible_user: The username used to authenticate with the ASA.
• ansible_password: The password associated with the user account.
• ansible_become_method: Set to enable to allow the transition from user mode to privileged EXEC mode.
• ansible_become_pass: The password required to enter the enable mode.
• ansible_connection: Set to network_cli to ensure the correct communication protocol is used for network devices.
• ansible_network_os: Set to asa to tell Ansible to use the specific logic and modules designed for Cisco ASA.

Example Inventory Structure:

```ini
[firewalls]
192.168.0.102
192.168.0.105

[firewalls:vars]
ansibleuser = ansible
ansiblepassword =
ansiblebecomemethod=enable
ansiblebecomepass=
ansibleconnection = networkcli
ansiblenetworkos = asa
```

Automating the Deployment of the Cisco ASA REST API

While the ASA can be managed via CLI emulation, activating the REST API unlocks more powerful programmatic capabilities, such as the ability to change passwords or modify policies via HTTP requests. Automating the deployment of the REST API ensures that the API is consistently enabled across all devices in the fleet.

Image Transfer via Bash and SCP

Before the REST API can be enabled via Ansible, the API image file (e.g., asa-restapi-7141-lfbff-k8.SPA) must be physically present on the device's flash storage (disk0:). Because Ansible's primary role here is configuration, the initial transfer of the large binary image is often handled by a specialized bash script using scp (Secure Copy Protocol).

In environments with older security settings, such as virtualized ASAv devices in EVE-NG, weak ciphers may be in use. This requires the use of specific flags to ensure the connection is not dropped by the SSH client. The following script demonstrates how to iterate through a list of devices in a device.txt file and push the image to the firewall.

```bash

!/bin/bash

Read Password

echo -n Password:
read -s password
echo

Run Command

echo $password
file=asa-restapi-7141-lfbff-k8.SPA
user=ansible
for device in $(cat device.txt)
do
sshpass -p $password scp -o KexAlgorithms=+diffie-hellman-group1-sha1 -o StrictHostKeyChecking=no $file $user@$device:disk0:$file
done
wait
```

This process ensures the binary is located at disk0:/asa-restapi-7141-lfbff-k8.SPA, allowing the subsequent Ansible playbook to activate the software.

Playbook Construction for REST API Activation

The Ansible playbook is written in YAML and utilizes the cisco.asa.asa_config module. This module allows the user to push a list of CLI commands to the device. To deploy the REST API, the playbook must move the device into enable mode and execute a sequence of commands.

The logic flow within the YAML file is as follows:

• Target hosts: Set to all to apply changes to every device listed in the inventory.
• Connection: Specified as network_cli.
• Fact Gathering: gather_facts: no is used to increase execution speed since the basic CLI commands do not require detailed system facts.
• Privilege Escalation: become: yes and become_method: enable are used to ensure the commands are executed with administrative privileges.

The specific commands pushed to the ASA are:

1. rest-api image disk0:/asa-restapi-7141-lfbff-k8.SPA: This tells the ASA to use the specified image file for the REST API service.
2. rest-api agent: This activates the REST API agent on the device.
3. http server enable: This enables the HTTP server required for API communication.
4. http 192.168.0.0 255.255.255.0 inside: This restricts HTTP access to a specific subnet on the inside interface for security purposes.

Complete YAML Playbook:

```yaml

• name: ASA Deploy REST API.
  hosts: all
  connection: network_cli
  

  connection: local

gatherfacts: no
becomemethod: enable
become: yes
tasks:
- name: ASA Deploy REST API
cisco.asa.asa_config:
commands:

- "show run"

• "rest-api image disk0:/asa-restapi-7141-lfbff-k8.SPA"
• "rest-api agent"
• "http server enable"
• "http 192.168.0.0 255.255.255.0 inside"
  

  - "show run rest-api"

```

Advanced Authentication and Key Management

For higher security environments, managing passwords in plain text within an inventory file is discouraged. An alternative is the use of SSH keys. This involves generating a public/private key pair on the Linux workstation.

When generating keys, the command typically looks like this:

bash ssh-keygen -t rsa -b 2048

During the prompt, the user specifies the file path, such as /home/user/.ssh/id_rsa. It is critical to note a technical quirk of the ASA OS: the key file name should not contain the underscore (_) character, as this can cause authentication failures during the registration of the public key on the ASA 5506.

Once the key is generated, the public key is registered to the ASA user account. This allows Ansible to authenticate via the SSH key instead of relying on a password, significantly improving the security posture of the management network.

Analysis of Management Limitations and Migration Paths

A critical distinction exists between managing the ASA OS and managing the integrated FirePOWER (SFR) modules. The methods described for the ASA OS—using network_cli and YAML playbooks—are effective for the firewall's core functions but do not extend to the SFR module's deep packet inspection and threat signatures.

If an organization requires the automation of the SFR module, the following paths are available:

• FMC Management: The ASA must be registered to a Cisco Firepower Management Center (FMC). Ansible can then be used to manage the FMC, which in turn pushes configurations to the SFR module on the ASA.
• Migration to FTD: The most robust solution is migrating from the ASA software image to FirePOWER Threat Defense (FTD). This involves a complete software migration and the activation of the FTD REST API. Once migrated, dedicated Ansible FTD modules can be used for comprehensive automation of both the firewall and the threat defense features.

Conclusion

The automation of Cisco ASA devices via Ansible transforms the operational efficiency of network security management. By transitioning from manual CLI entry to a structured approach involving INV.INI inventory files and YAML playbooks, administrators can eliminate the inconsistencies that lead to security vulnerabilities. The process begins with the establishment of a stable Linux control node, followed by the precise definition of network variables and the use of network_cli for communication.

The ability to automate the deployment of the REST API—starting with the programmatic transfer of the .SPA image via SCP and concluding with the execution of configuration commands—demonstrates the power of combining bash scripting with Ansible. While the ASA 5506 provides a solid platform for this automation, the inherent limitations regarding the SFR module highlight the necessity of understanding the architectural differences between the ASA OS and the FTD ecosystem. Ultimately, the use of Ansible not only reduces the time spent on mundane tasks but also provides a scalable framework for pushing updates, patches, and common configuration changes across an entire enterprise infrastructure.

Sources

1. How to manage an ASA 5506 with Ansible
2. Automating the Deployment of the Cisco ASA REST API