Ansible for Config Backup & Compliance: — Catching Network Drift Before It Bites

① The drift + backup problem — the midnight change nobody recorded

Picture Rahul, an L1 network engineer at Infosys, on a Monday morning. A core switch at the Pune campus stopped passing a VLAN over the weekend. Someone — nobody is owning up — logged in around 2 a.m. on Saturday and "fixed" something by hand on the CLI. There is no ticket, no email, no record of what they typed. Rahul opens the switch and sees the current config, but he has nothing to compare it against. He cannot answer the only question that matters: what changed, and what did it look like before?

This is configuration drift, and it is the quiet killer of network ops. Every undocumented hand-edit — a quick no shutdown, a temporary ACL line "just for testing", an SNMP community string added for a vendor — pushes the live running-config a little further from what your design documents say it should be. Each one is harmless alone. Together they mean that on the day of an outage, nobody can roll back to a known-good state, because nobody recorded one.

The second half of the same problem is compliance. Your security policy says: no telnet, SNMPv3 only (no clear-text SNMPv1/v2c community strings), an approved NTP server set, and AAA configured for login. But who checks that on all 200 devices, every night? In most shops the honest answer is "nobody, until the auditor asks" — and by then the drift has been live for months.

Here is the shift. Ansible can log into every device on a schedule, pull the full running-config, and save it to a timestamped file — that is the backup. Commit each night's pull into Git and you suddenly have a full, dated change history with diffs. Then, in the same nightly run, Ansible reads the running state and asserts it against your written policy — and the play fails the host that drifted. Backup answers "what changed"; compliance answers "is it still allowed". Both, unattended, every night.

The four faces of the drift problem

Tap each card — these are the four pains every "we need config backup and compliance" project starts from.

② Backup playbooks — ios_config backup, timestamped files, committed to Git

The fastest backup uses the cisco.ios.ios_config module with one switch: backup: true. When set, Ansible logs into each device, grabs the running-config, and writes it to a file on the control node. By default that file lands in a backup/ folder next to your playbook, named <hostname>_config.<date>@<time>. That default naming is already timestamped — but in real life you control it with backup_options.

backup_options takes two sub-options: dir_path (where the file goes) and filename (what it is called). This is how you organise backups by hostname and date so the folder stays sane across 200 devices. A common pattern: one directory per device, file named with a date stamp — so backups/BR-Mumbai-rtr01/2026-06-11.cfg sits next to yesterday's file and git diff between them is meaningful.

---
- name: Nightly config backup
  hosts: ios_devices
  gather_facts: false
  vars:
    backup_root: "/home/netauto/backups"
  tasks:
    - name: Pull running-config and save a timestamped copy
      cisco.ios.ios_config:
        backup: true
        backup_options:
          dir_path: "{{ backup_root }}/{{ inventory_hostname }}"
          filename: "{{ lookup('pipe','date +%Y-%m-%d') }}.cfg"
      register: backup_result

    - name: Show where each backup landed
      ansible.builtin.debug:
        var: backup_result.backup_path

PLAY [Nightly config backup] ***************************************
TASK [Pull running-config and save a timestamped copy] *************
ok: [BR-Mumbai-rtr01]
ok: [BR-Pune-rtr01]
TASK [Show where each backup landed] *******************************
ok: [BR-Mumbai-rtr01] => { "backup_result.backup_path": "/home/netauto/backups/BR-Mumbai-rtr01/2026-06-11.cfg" }
PLAY RECAP *********************************************************
BR-Mumbai-rtr01 : ok=2  changed=0  unreachable=0  failed=0

Notice changed=0 in the recap — pulling a backup does not change the device, so a read-only backup run is safe to schedule. (If you do not use a Cisco IOS device, the same idea works with *_command modules: run show running-config, then write the captured output to a file with copy_to/ansible.builtin.copy. The *_config backup option is just the tidy shortcut where it exists.)

A folder of dated files is useful; a Git repository of them is powerful. After the backup task, run a couple of shell tasks (or the ansible.builtin.git-adjacent pattern) to git add, git commit with a dated message, and push. Now every night's configs are a commit. When the Pune router breaks, you run git log on its file, find Saturday's 2 a.m. commit, run git diff, and see the exact line someone added — with a timestamp and author. That is the difference between "something changed" and "this line changed, at this time".

cd /home/netauto/backups
git add -A
git commit -m "Nightly config backup 2026-06-11" || echo "No changes to commit"
git push origin main

[main 7c4e1a9] Nightly config backup 2026-06-11
 2 files changed, 11 insertions(+), 3 deletions(-)
 rewrite BR-Pune-rtr01/2026-06-11.cfg (78%)
To github.com:infosys-netauto/network-backups.git
   3b21f0c..7c4e1a9  main -> main

③ Compliance checking — read the running state, assert the policy, fail the drifter

Backup is the camera. Compliance is the auditor. The pattern is always the same three moves: (1) read the running state, (2) assert it against a written policy, (3) fail the host that violates it. To read state you use either ios_facts (structured facts under ansible_net_* keys) or ios_command (raw show output you grep with filters).

The enforcer is the assert module. You hand it a list of conditions under that: and a fail_msg. If every condition is true, the host passes; if any is false, that host fails the play and your message names the violation. So your policy — no telnet, SNMPv3 only, NTP set, AAA configured — becomes a list of assert conditions, and the play recap turns red for exactly the devices that drifted.

---
- name: Network security compliance check
  hosts: ios_devices
  gather_facts: false
  tasks:
    - name: Grab the full running-config
      cisco.ios.ios_command:
        commands: ["show running-config"]
      register: rc

    - name: Assert the device meets policy
      ansible.builtin.assert:
        that:
          - "'transport input telnet' not in rc.stdout[0]"     # no telnet
          - "'snmp-server community' not in rc.stdout[0]"      # SNMPv3 only, no v1/v2c
          - "'ntp server 10.10.0.10' in rc.stdout[0]"          # approved NTP set
          - "'aaa new-model' in rc.stdout[0]"                  # AAA configured
        fail_msg: "NON-COMPLIANT: telnet/SNMPv2/NTP/AAA policy violated"
        success_msg: "Compliant"

TASK [Assert the device meets policy] ******************************
ok: [BR-Mumbai-rtr01] => { "msg": "Compliant" }
fatal: [BR-Pune-rtr01]: FAILED! => {"assertion": "'transport input telnet' not in rc.stdout[0]",
        "evaluated_to": false, "msg": "NON-COMPLIANT: telnet/SNMPv2/NTP/AAA policy violated"}
PLAY RECAP *********************************************************
BR-Mumbai-rtr01 : ok=2  changed=0  failed=0
BR-Pune-rtr01   : ok=1  changed=0  failed=1

Read the recap: Mumbai passed, Pune failed=1 — and the failing assertion text tells you which condition broke. That is the whole point: a single play run, across every device, produces a precise red/green list. No human eyeballing 200 configs.

Now the design decision that trips up every beginner: report-or-remediate. A report-only play asserts and fails but touches nothing — safe to run nightly, unattended, against production. A remediate play goes further: when it finds telnet, it removes it with ios_config. Remediation is powerful but it changes production, so you gate it behind a change window, --check dry-runs first, and human approval. The classic newbie error is wiring auto-remediation into the nightly cron and discovering, at 3 a.m., that the play "fixed" a temporary change an engineer needed.

④ A real pipeline — backup → commit → assert → report, end to end

Now we stitch the pieces into one nightly pipeline. The shape every shop converges on: (1) backup every device → (2) git commit the pull → (3) compliance assert against policy → (4) report the red/green result to the team (email, Slack, or an artifact). Steps 1–2 give you history; steps 3–4 give you the audit. Run it from cron tonight, and tomorrow you have both — for every device, automatically.

A worked example — "detect a device still running telnet and remediate it". The nightly report flags BR-Pune-rtr01 (telnet found). That is the detect. The next morning, in the approved change window, an engineer runs the remediate play with a --check dry-run, eyeballs the diff, then applies it. The play sets transport input ssh, telnet is gone, and that evening's backup + compliance run both come back green. Detect at night, remediate by day, prove it with the next backup.

---
- name: Remediate telnet on flagged hosts
  hosts: "{{ target | default('ios_devices') }}"
  gather_facts: false
  tasks:
    - name: Force SSH-only on VTY lines (no telnet)
      cisco.ios.ios_config:
        lines:
          - transport input ssh
        parents: line vty 0 15
      register: fix

    - name: Report what changed
      ansible.builtin.debug:
        msg: "{{ 'remediated' if fix.changed else 'already compliant' }}"

# dry run first:  ansible-playbook remediate-telnet.yml -e target=BR-Pune-rtr01 --check --diff
--- before
+++ after
@@ line vty 0 15 @@
- transport input telnet ssh
+ transport input ssh
changed: [BR-Pune-rtr01]
TASK [Report what changed] => { "msg": "remediated" }

There is a slicker, declarative way to detect drift too: ios_config can take diff_against: intended with an intended_config baseline, and Ansible reports the difference between the device and your golden config. Its sibling choices are diff_against: running (before/after of your change) and diff_against: startup (running vs startup). For a "does this match my approved baseline" check, intended is the one that maps to drift detection.

Three gotchas that bite real pipelines. One — secrets in saved configs. Running-configs carry SNMP communities and TACACS keys; if your Vault password or those configs leak you have a breach. This is not theoretical: CVE-2024-8775 showed Ansible Vault secrets exposed in plaintext in playbook output, and CVE-2024-0690 showed no_log not being respected in some loop scenarios — so put no_log: true on any task touching secrets and keep backup repos private. Two — huge diffs from timestamps. Strip volatile clock/timestamp lines or every backup looks changed. Three — false drift from loose matches. Assert on the real config line, not a substring, or harmless text triggers a red.

ram@netauto:~/playbooks$ ansible-playbook -i inventory.ini backup.yml && \
  bash commit-backups.sh && \
  ansible-playbook -i inventory.ini compliance.yml

PLAY RECAP (backup.yml) *** BR-Mumbai-rtr01: ok=2 changed=0   BR-Pune-rtr01: ok=2 changed=0
[main 7c4e1a9] Nightly config backup 2026-06-11 | 2 files changed, 11 insertions(+), 3 deletions(-)
TASK [Assert the device meets policy] ***
ok: [BR-Mumbai-rtr01] => "Compliant"
fatal: [BR-Pune-rtr01]: FAILED! => "NON-COMPLIANT: telnet/SNMPv2/NTP/AAA policy violated"
PLAY RECAP (compliance.yml) *** BR-Mumbai-rtr01: failed=0   BR-Pune-rtr01: failed=1

On the RHCE EX294 blueprint, this lesson lives where it counts: writing playbooks with tasks, variables and conditionals, using modules correctly, and — directly relevant here — protecting credentials with Ansible Vault. The 2026 exam runs on ansible-navigator with execution environments. The backup/assert pattern you just learned is the same task-and-module muscle the exam tests; the Vault + no_log discipline is the security objective. Career-wise, "we automate config backup and nightly compliance" is one of the most common first real jobs handed to a junior on a network automation desk.