Jenkins Pipeline for Network Config Compliance

Configuration compliance usually fails for a prosaic reason: nobody runs the check. Devices are backed up nightly to a Git repository, the repository slowly accumulates drift - a missing NTP server, telnet left enabled, SNMP community still public - and the audit finds it a year later. Treating configuration backups as code fixes that: a Jenkins pipeline scans the repository on every commit and in a nightly job, fails the build on violations and publishes results where engineers already look.

What the pipeline needs

• Backups in Git - one file per device, filename = hostname. Any collection method works; Ansible Network Resource Modules: Declarative Config shows how Ansible can gather and persist them.
• Policy packs - versioned YAML rules with severity, scope (global, interface, VLAN) and remediation text.
• A scanner - network-config-checker is one good option: it runs entirely offline against text configs, needs no device credentials, and emits TXT, JSON, HTML, CSV, SARIF and JUnit.

Jenkinsfile

pipeline {
  agent any
  triggers { cron('H 3 * * *') }          // nightly fleet scan
  stages {
    stage('Checkout backups') {
      steps { checkout scm }
    }
    stage('Validate policy packs') {
      steps {
        sh 'network-config-checker validate-policies -p policies/builtin'
      }
    }
    stage('Compliance scan') {
      steps {
        sh '''network-config-checker scan -c configs -p policies/builtin \
              -o reports --format txt,json,junit,sarif --fail-on high'''
      }
    }
    stage('Drift vs baseline') {
      steps {
        sh 'network-config-checker scan -c configs -p policies/builtin --baseline baseline.json || true'
      }
    }
  }
  post {
    always {
      junit 'reports/*.xml'
      archiveArtifacts artifacts: 'reports/**', allowEmptyArchive: true
    }
    failure {
      echo 'Compliance violations found - see archived report'
    }
  }
}

Exit codes make the gate usable: 0 = clean, 1 = violations at or above the --fail-on threshold, 2 = runtime or configuration error. A non-zero exit fails the build, which is exactly what you want on a pull request that modifies configs/.

Example policy rule

policy_pack_name: cisco_ios_baseline
policy_pack_version: "1.0.0"
rules:
  require_ntp:
    id: NCC-REQUIRE-NTP
    description: Device must reference an authorised NTP server
    severity: medium
    scope: global
    required_conditions:
      - "regex:ntp server\\s+10\\.10\\.0\\.(1|2)"
    remediation: |
      ntp server 10.10.0.1
      ntp server 10.10.0.2

Write rules with remediation text. A scan that only says "violated" costs an engineer half an hour; one that prints the exact commands costs two minutes.

Scaling the workflow

1. Start with the two built-in packs (baseline and management hardening) and a single --fail-on high gate, so the first week does not produce a thousand findings nobody fixes.
2. Add a CSV inventory (hostname,path) once devices move between folders, or use a directory glob per site.
3. Keep the baseline JSON and diff against it: the report then answers "what changed since yesterday" rather than "what is wrong today", which is far easier to assign. The same intent as rollback-based safety nets in Cisco IOS XR Commit Replace and Rollback Configuration - make the change visible before it reaches production.

原文链接：https://github.com/akintunero/network-config-checker