Network Automation, Security & AI

Everything downstream assumes the first few rungs of this ladder.

The mindset shift

Legacy networking rewards knowing the box — the CLI, the quirks, the war stories. Automation rewards describing the intent and letting a tool apply it identically every time. Twenty years of CLI knowledge isn't discarded; it's exactly what makes the automation correct. The tool is fast and consistent. The engineer is the one who knows what "correct" means.

The skills ladder — what to learn, in order

One rung at a time. Each is useful on its own, so the investment pays off even if progress pauses. Don't skip rung 1 — Git and a comfortable shell remove most of the friction later.

A realistic 90-day plan

Two focused hours a few times a week is enough. By day 90 you'll have done, on lab gear, the exact first three things any platform needs: backup, inventory, and one compliance check.

Free places to practice — no lab gear required

None of this requires production access, or even owning hardware.

The core toolset — and why each exists

Cloud learning paths (free): Azure network foundations · AWS VPC docs. Community: NetworkToCode Slack, r/networking, and the Packet Pushers automation podcasts.

Where AI actually fits — and where it must not

AI is a genuine accelerator for an engineer moving into automation, but it belongs in the authoring and diagnosis seat, not the apply seat. Use it to move faster; keep the guardrails — review, approvals, testing — exactly as strict.

Good uses — start here

• Explain-this: paste a playbook, config, or error — "what does this do, why did it fail?" A patient tutor that never tires.
• Draft-then-review: "Write a Jinja2 template for an access port with a voice VLAN." Every line gets reviewed before it touches anything.
• Translate: "Convert these CLI commands into an Ansible task." Ideal for migrating knowledge you already have.
• Log and alert triage: summarize noisy syslog, cluster similar events, draft a first-pass root cause.
• Docs Q&A and ChatOps (later): ask vendor docs precise questions; a chat command triggers a read-only diagnostic job.

The A–Z blueprint. Part A is how an individual gets ready to build this; Part B is what "this" is.

The golden path — every production change follows it

Automate safely — earn trust before touching production:

Discover → Back up → Validate → Report → Remediate (with approval) → Controlled production changes

Don't start by auto-changing production firewall policy, routing, or core switches. Prefer, in order: Vendor API → Ansible resource module → NETCONF/RESTCONF → Vendor CLI module → raw CLI (last resort).

Platform architecture

Component responsibilities

Firewall and ADC workflows

Firewall changes run: app owner → network/security review → source, destination, port and protocol verified → change ticket → automation builds proposed policy → pre-change validation → commit → connectivity test → evidence attached to the ticket.

Safety controls: no any-any without security approval, temporary rules carry mandatory expiration dates, backup before major changes, post-change traffic validation required.

VIP creation on an application delivery controller runs: request → validate IP in the source of truth → validate DNS → validate certificate → services and service group → health monitor → VIP → bind SSL certificate → persistence and policies → validate backend and frontend → update source of truth and ITSM.

Maturity model

A phased path from zero to governed automation. Durations are indicative for a mid-size estate; the sequence matters far more than the calendar.

Security, roles & environments

Roles: Automation Admin (platform; cannot bypass production review) · Developer (builds and tests, opens PRs; no direct production execution) · Network Engineer (runs approved jobs in an assigned area) · Approver · Service Desk (limited self-service) · Auditor (read-only logs, changes, reports).

Access: SSO · MFA · RBAC · least privilege · dedicated service accounts · quarterly access reviews · centralized audit logging · no shared accounts · no clear-text credentials · production separated from development.

Environments: Development → Lab → Test → Pre-Production → Production, each with separate inventories, credentials, orchestration projects, protected branches, and cloud identities. Production never uses development credentials. Every production change is traceable: requestor, approver, ticket, timestamp, target, previous and proposed config, commands run, validation results, final and rollback status.

Certificates — a first-class network responsibility

Certificates attach to ADC VIPs, Azure Application Gateway, AWS ALB/NLB, firewalls, VPN gateways, wireless controllers, and management interfaces. Track name, CN, SANs, issuer, serial, expiration, owner, location, listener binding, renewal process, and private-key location. Private keys are never committed to a repository.

Azure App Gateway pattern: Enterprise PKI/CA → Key Vault → Managed Identity → App Gateway → HTTPS listener. Monitoring stays with the monitoring platform — automation does not replace it.

What makes this enterprise-grade rather than a pile of scripts — the Well-Architected alignment and the control mapping leadership, security, and auditors will ask for.

Enterprise design tenets

Every decision in Part B traces back to five non-negotiable tenets. In a regulated environment where sensitive data may traverse or depend on the network, these separate automation from governed automation.

Well-Architected Framework alignment

Because the footprint spans on-premises, Azure, and AWS, the platform is evaluated against AWS Well-Architected (6 pillars) and Azure Well-Architected (5 pillars) in parallel.

Security architecture — defense in depth

Layer 1  Identity        SSO + MFA · RBAC · dedicated service accounts · no shared logins
Layer 2  Authorization   Least privilege · per-area scoping · approval gates for sensitive jobs
Layer 3  Secrets         Managed vault · short-lived, scoped · never in a repo or a log
Layer 4  Change control  Pull request + peer review + code owners + CI (lint/syntax/secret-scan)
Layer 5  Validation      Pre-change reachability + post-change verification + drift detection
Layer 6  Segmentation    Automated, reviewed firewall/NSG/SG policy · no any-any without approval
Layer 7  Detection       SIEM ingest of all job + config-change events · unauthorized-change alerts
Layer 8  Recovery        Nightly backups · tested rollback · HA + DR-path validation

No single layer is trusted to be sufficient. A failure or bypass at one layer is contained by the others — the core requirement behind both the HIPAA risk-management standard and HITRUST's control depth.

Compliance control mapping

The table auditors and security leadership ask for. Each platform capability maps to the HIPAA Security Rule (45 CFR Part 164, Subpart C), the SOC 2 Trust Services Criteria (AICPA TSP §100), and the relevant HITRUST CSF domain.

Continuous compliance — the platform produces its own evidence

The strongest audit posture is one where evidence is a byproduct of normal operation, not a scramble before an assessment.

# Every production change automatically yields:
  requestor + approver + change ticket    →  access-control & change-mgmt evidence
  timestamped commit + peer review        →  integrity & separation-of-duties evidence
  job log + automation output             →  audit-control evidence (who / what / when)
  pre- and post-change validation results →  processing-integrity evidence
  SIEM record of all of the above         →  monitoring & non-repudiation evidence

Regulated-data handling rules inside automation

• No regulated data in configs, repositories, logs, backups, or AI prompts. Sanitize device backups before storage.
• No secrets, private keys, or credentials in a repository or clear-text inventory — vault only; scrubbed from job output.
• Encrypt in transit and at rest: SSH/HTTPS/API/NETCONF for access; encrypted backup storage; TLS between platform components.
• Segregate environments: production never uses development credentials or identities.
• Execute the appropriate agreements with any third party that could process regulated data before it enters a production workflow.

Small and real. Point these at a free sandbox or a Containerlab topology — never production — until you trust them.

D.1 · First script — Netmiko "hello world"

# show_version.py — SSH to a device and print facts.  pip install netmiko
from netmiko import ConnectHandler

device = {
    "device_type": "cisco_ios",
    "host": "sandbox-iosxe-latest-1.cisco.com",  # public DevNet sandbox
    "username": "admin",
    "password": "C1sco12345",                       # published sandbox credential
}
with ConnectHandler(**device) as conn:
    print(conn.send_command("show version"))
    print(conn.send_command("show ip interface brief"))

Run python show_version.py — that's a device automated.

D.2 · Ansible nightly config backup (use case #1)

# playbooks/backup/backup_ios.yml
- name: Back up Cisco IOS running-config
  hosts: ios
  gather_facts: false
  tasks:
    - name: Pull running-config
      cisco.ios.ios_command:
        commands: show running-config
      register: run
    - name: Save to a dated file
      ansible.builtin.copy:
        content: "{{ run.stdout[0] }}"
        dest: "backups/{{ inventory_hostname }}-{{ ansible_date_time.date }}.cfg"
      delegate_to: localhost

ansible-playbook -i inventories/lab/hosts.yml playbooks/backup/backup_ios.yml

Schedule that same command as a nightly Rundeck job and use case #1 is done. Credentials come from a vault or the orchestrator's key storage — never clear-text in the inventory.

D.3 · A read-only compliance check (use case #4)

# Compliance — Telnet must be disabled
- name: Read VTY transport config
  cisco.ios.ios_command:
    commands: show running-config | section vty
  register: vty
- name: Fail if Telnet is permitted
  ansible.builtin.assert:
    that: "'transport input telnet' not in vty.stdout[0]"
    fail_msg: "{{ inventory_hostname }}: Telnet ENABLED — non-compliant"

This reports a problem; it changes nothing. That's exactly how trust gets built before automating fixes.

D.4 · Config from a template — Jinja2

# templates/ios/access_port.j2
interface {{ interface }}
 description {{ description }}
 switchport mode access
 switchport access vlan {{ access_vlan }}
{% if voice_vlan is defined %} switchport voice vlan {{ voice_vlan }}
{% endif %} spanning-tree portfast

Feed it a data file and the same correct port config renders every time — no more copy-paste drift.

D.5 · CI that guards every change

# .github/workflows/lint.yml
on: [pull_request]
jobs:
  ansible-lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install ansible ansible-lint yamllint
      - run: yamllint .
      - run: ansible-lint playbooks/
      - uses: gitleaks/gitleaks-action@v2   # secret scan

Every pull request is now auto-checked for style, syntax, and leaked secrets before a human reviews it. That's the whole idea in one file.

D.6 · The scheduled job that ties it together

# Rundeck job definition
- name: Back Up All Network Configurations
  group: Network/Backup
  schedule:
    time: { hour: "2", minute: "0" }   # nightly 02:00
  options:
    - name: environment
      values: [lab, test, production]
      required: true
  sequence:
    commands:
      - script: |
          ansible-playbook \
            -i inventories/${option.environment}/hosts.yml \
            playbooks/backup/backup_ios.yml
  notification:
    onfailure:
      plugin: { type: itsm-incident }   # auto-open a ticket on failure

A scheduled, logged, role-controlled front door to the exact playbook from D.2 — with an automatic incident if the backup fails.