Infrastructure as Code: Using SaltStack for Network Configuration

This post introduces SaltStack as an infrastructure as code tool for network configuration. It walks through setting up proxy minions for agentless network devices, writing NAPALM-backed state files, and applying configuration changes using Salt's master/minion architecture.

Infrastructure as Code: Using SaltStack for Network Configuration

Network engineers are increasingly expected to manage infrastructure through code rather than manual CLI sessions. Infrastructure as code (IaC) brings repeatability, version control, and scalability to network configuration, and SaltStack is one of the most powerful tools available for doing exactly that. If you are familiar with Ansible but want to explore an event-driven, agent-capable alternative, SaltStack is worth your attention.

What Is SaltStack?

SaltStack (often just called Salt) is an open-source automation and configuration management platform originally developed by Thomas Hatch in 2011. It was acquired by VMware in 2020 and continues to be managed under VMware, which is itself now a subsidiary of Broadcom. Salt uses a master/minion architecture where a central Salt Master pushes configuration to Salt Minions running on managed nodes. For network devices that cannot run an agent, Salt also supports an agentless proxy minion model, which is the approach most network engineers will use.

Salt communicates over a high-speed message bus using ZeroMQ, making it extremely fast compared to SSH-polling tools. It also supports event-driven automation, meaning you can trigger configuration changes in response to real-time events on your network.

Core Concepts Before You Start

💻
The best SSH/Telnet client I've ever used: If you're doing serious CLI work daily, SecureCRT is the best terminal client I've come across in 20+ years of networking. I don't currently have a licence because I'm not doing enough console work to justify the cost — but the moment that changes, it's the first thing I'd buy. PuTTY is free and gets the job done, but SecureCRT is in a different league.

Before diving into network configuration, you need to understand three Salt building blocks:

  • States: declarative configuration files written in YAML that describe the desired state of a system
  • Grains: static data about a minion, such as its OS, role, or device type
  • Pillars: sensitive or environment-specific data stored securely on the master and pushed to minions on demand

These three components work together to give you flexible, data-driven network configuration management.

Setting Up a Proxy Minion for Network Devices

Most network devices cannot run a Salt Minion directly. Instead, you run a proxy minion on a Linux host that acts as an intermediary between the Salt Master and your router or switch. Salt supports several network proxy modules, including napalm, which works with Cisco IOS, NX-OS, Junos, EOS, and more.

First, install the required packages on your proxy host:

pip install salt napalm

Next, define your proxy configuration in /etc/salt/proxy:

master: 192.168.1.10

Then create a pillar file that describes the device connection details. In /srv/pillar/router01.sls:

proxy:
  proxytype: napalm
  driver: ios
  host: 192.168.1.1
  username: admin
  password: secretpassword

Start the proxy minion process targeting your device:

salt-proxy --proxyid=router01 -d

Accept the minion key on the master:

salt-key -a router01

Verify connectivity with a test ping:

salt router01 test.ping

Writing a Network State File

Once your proxy minion is connected, you can write Salt states to manage configuration. The napalm module provides execution functions that let you apply configuration templates using Jinja2.

Create a state file at /srv/salt/ntp_config.sls:

configure_ntp:
  napalm.load_template:
    - template_name: salt://templates/ntp.j2
    - test: False

Create the Jinja2 template at /srv/salt/templates/ntp.j2:

ntp server 10.0.0.1
ntp server 10.0.0.2
ntp source Loopback0

Apply the state to your device:

salt router01 state.apply ntp_config

Salt will render the template, connect to the device via NAPALM, and apply the configuration. The output confirms which changes were committed and whether any errors occurred.

Why SaltStack Stands Out for Network Automation

Salt offers several advantages that make it compelling for infrastructure as code in networking environments:

  • Speed: ZeroMQ-based communication is significantly faster than SSH polling
  • Targeting flexibility: apply states to devices based on grains like role, site, or platform using a single command
  • Event-driven automation: trigger remediation or configuration pushes automatically when a device reports an event
  • Idempotency: Salt states only make changes when the current state differs from the desired state

What's Next

Now that you understand how SaltStack connects to network devices and applies configuration through states, the next step is exploring Salt's reactor system. The reactor allows you to define automated responses to network events, which takes your infrastructure as code practice from scheduled configuration pushes to true event-driven network automation. We will cover that in an upcoming post.

🔧
Before you fully automate with SaltStack, SecureCRT is a solid choice for structured CLI sessions — it supports scripting and session logging that can help you prototype the configurations you will later codify as Salt states. SecureCRT, Ansible and Netmiko.