Managing FTD FMC with Terraform

Introduction

Security infrastructure demands precision. When you manage Firepower Threat Defense (FTD) appliances and Firepower Management Center (FMC) across an enterprise, the sheer volume of access control policies, network objects, NAT rules, and intrusion prevention settings makes manual configuration both slow and error-prone. Every time an engineer deploys changes by hands-on-keyboard via a GUI or CLI, mistakes happen — it is simply a reality of human-driven operations.

Terraform offers a way out of that cycle. As an Infrastructure-as-Code (IaC) provisioning tool, Terraform lets you define your entire FTD and FMC configuration in declarative files, store those files in version control, and push changes through a repeatable, auditable pipeline. The real goal with automation and orchestration is standardization — the ability to deploy quickly while maintaining standards, speed, and flexibility.

In this lesson, you will learn how Terraform's core properties make it an ideal tool for managing security appliances, how the IaC workflow applies to FTD and FMC environments, and how tools like Atlantis bring collaboration and visibility to the process.

Key Concepts

Terraform Fundamentals

Terraform is an open-source infrastructure provisioning tool with commercial support from HashiCorp. It is built around several properties that make it especially powerful for managing network and security devices:

Property	Description
Declarative	You describe the desired end state; Terraform determines how to reach it
Idempotent	Running the same configuration multiple times produces the same result without unintended side effects
Immutable infrastructure	Rather than modifying resources in place, Terraform can replace them to ensure consistency
Agentless	A single binary file with zero server-side dependencies — nothing needs to be installed on the managed device
Multi-platform	Can manage a wide range of systems: VMs, network devices, cloud instances, and more

These properties are critically important for security infrastructure. FTD and FMC configurations must be consistent, auditable, and reproducible. A declarative, idempotent approach ensures that what you define in code is exactly what gets deployed — every single time.

Infrastructure as Code for Security

The core principles of IaC apply directly to FTD and FMC management:

• Automate the provisioning and management of your security technology stack
• Translate manual tasks into reusable, robust, distributable code
• Rely on practices that have been successfully used for years in software development: version control, automated testing, release tagging, and continuous delivery

The benefits are measurable: much higher delivery speed and a significant reliability boost compared to manual configuration through the FMC web interface.

The Automation Progression

Understanding where Terraform fits in the broader automation journey helps frame its value. Network and security automation has evolved through several stages:

1. APIs — Direct API calls (for example, using tools like Postman) to interact with FMC's REST API
2. SDKs — Writing scripts in Python or Go to programmatically manage security policies
3. IaC Tools — Using Terraform or Ansible to define infrastructure declaratively
4. Source Control — Storing all configuration in a version control system (VCS) as the single source of truth
5. CI/CD Pipelines — Automating the full lifecycle from code commit to production deployment

Terraform sits at the IaC layer, but its real power emerges when combined with source control and pipeline automation.

How It Works

The Terraform Workflow for FTD and FMC

Terraform uses HCL (HashiCorp Configuration Language) files to define resources. When managing FTD and FMC, you write HCL that describes the security objects, policies, and settings you want to exist on your FMC. Terraform then communicates with the FMC API to create, update, or remove those resources to match your declared state.

The workflow follows a consistent pattern:

1. Write — Define your FTD/FMC resources in .tf files using HCL
2. Plan — Terraform compares the desired state in your HCL files against the current state of the infrastructure and shows what changes it will make
3. Apply — Terraform executes the planned changes against the FMC API
4. Track — Terraform maintains a state file that records the current state of all managed resources

Because Terraform is agentless with zero server-side dependencies, no software needs to be installed on the FMC or FTD appliances themselves. Terraform communicates entirely through the management API.

Automating the Workflow with Atlantis

Managing Terraform in isolation works, but teams need collaboration and governance. Atlantis is an open-source tool that automates Terraform workflows using source code management (SCM) pull requests.

Here is how the apply action works with Atlantis:

Step	Action
1	User commits HCL to the version control system (VCS)
2	VCS sends a webhook to the Atlantis URL
3	Atlantis pulls the VCS files and applies them towards the infrastructure
4	Results of the apply and state are tracked by the Atlantis server
5	Atlantis updates the results via a pull request comment

Key characteristics of Atlantis:

• Connects to your SCM using webhooks and comments the results of plan, apply, and import operations directly into the pull request
• Runs locally as a Go binary or Docker container — no cloud dependency
• Credentials are never committed to the SCM — they stay on the Atlantis server
• All history is logged, providing full collaboration and visibility amongst teams

This means that when an engineer wants to change a firewall policy, they submit a pull request. Atlantis automatically runs terraform plan, posts the output as a PR comment, and the team can review exactly what will change before approving. Once approved, Atlantis runs terraform apply and posts the results. Every change is reviewed, tracked, and auditable.

Abstraction at the Tooling Level

Atlantis represents a broader concept of abstraction at the tooling level. Prebuilt applications perform actions using drivers from IaC files, while common boilerplate services such as linting and validation are handled by the application itself. Integration uses open methods — webhooks and access tokens — to connect the SCM to the application and build server.

For FTD and FMC management, this means your typical pipeline performs several functions automatically:

• Linting of HCL source code to catch syntax errors before deployment
• Deploy to test/dev/QA environment to validate changes in a non-production setting
• Validation of test environment functionality to confirm policies behave as expected
• Deploy to production environment once validation passes
• Validation of production environment to confirm the rollout succeeded

Configuration Example

Terraform configurations for FTD and FMC follow standard HCL structure. Below is an example of how you would define a Terraform provider block and basic resource for managing security infrastructure.

First, you configure the Terraform provider to connect to your FMC:

terraform {
  required_providers {
    fmc = {
      source = "CiscoDevNet/fmc"
    }
  }
}

provider "fmc" {
  fmc_host     = "fmc.lab.nhprep.com"
  fmc_username = "admin"
  fmc_password = "Lab@123"
  fmc_insecure_skip_verify = true
}

The provider block tells Terraform how to connect to the FMC appliance. Because Terraform is agentless with zero server-side dependencies, this provider handles all communication with the FMC REST API from the workstation where Terraform runs.

To verify that Terraform can communicate with your infrastructure, use the standard Terraform commands:

terraform init

This initializes the working directory and downloads the required provider plugins.

terraform plan

This shows you exactly what Terraform intends to create, modify, or destroy — without making any changes. Review this output carefully before proceeding.

terraform apply

This executes the planned changes against your FMC. Terraform will prompt for confirmation before proceeding.

Best Practice: Always run terraform plan and review the output before running terraform apply. In a team environment, use Atlantis so that plan output is posted to pull requests for peer review before any changes reach production.

Real-World Application

Production Deployment Scenarios

Terraform-driven FTD and FMC management is most valuable in environments where:

• Multiple FTD appliances are managed by a single FMC, and consistent policy deployment is critical
• Change control processes require audit trails — every Terraform change is captured in version control with full commit history
• Multiple engineers collaborate on security policy changes — Atlantis provides visibility so the entire team can see and review proposed changes
• Disaster recovery demands the ability to rebuild security configurations from code rather than from manual documentation or backups

Design Considerations

When adopting Terraform for FTD and FMC management, keep these principles in mind:

• Source control is the single source of truth — all security policy definitions live in your VCS repository, not in ad-hoc scripts or manual documentation
• Credentials never go into source control — use Atlantis or environment variables to keep FMC credentials on the server, never committed to the repository
• Test before production — use the pipeline approach of deploying to a test environment first, validating functionality, and only then deploying to production
• Standardization drives reliability — the real goal of automation is not speed alone but the ability to maintain standards across every deployment

Important: Terraform's declarative nature means it will enforce the state defined in your HCL files. If someone makes a manual change on the FMC outside of Terraform, the next terraform apply will revert that change. This is by design — it enforces the principle that code is the single source of truth.

Simulation and Testing with CML2

For testing Terraform configurations before deploying to production security appliances, CML2 (Cisco Modeling Labs 2) provides an API-driven virtual network function (VNF) topology builder and simulation software. CML2 includes support for both Ansible and Terraform, making it possible to validate your IaC workflows in a safe, isolated lab environment before touching production FTD and FMC appliances.

Summary

• Terraform is an open-source, agentless, declarative, and idempotent IaC tool that can manage FTD and FMC security infrastructure with zero server-side dependencies
• Infrastructure as Code translates manual security configuration tasks into reusable, version-controlled code, delivering higher deployment speed and significant reliability improvements
• Atlantis automates Terraform workflows through SCM pull requests, providing full collaboration, visibility, and audit history without committing credentials to source control
• Pipeline automation enforces a disciplined process: lint, deploy to test, validate, deploy to production, and validate again
• Standardization is the ultimate goal — Terraform ensures that security policies are deployed consistently every time, eliminating the configuration drift that comes with manual management

In the next lesson, we will bring these concepts together by examining end-to-end Terraform workflows for Cisco infrastructure, tying together the networking and security automation patterns covered throughout this course.