Network Automation Security: Securing Controller Tokens, Automation Accounts and Pipeline Pushes

Network automation concentrates the power of every network engineer into a handful of service accounts, API tokens and pipelines that can rewrite the whole fabric in one run. Once a team moves from typing commands to pushing changes through Ansible, NETCONF, RESTCONF, a source of truth such as NetBox or a vendor controller, the identity that matters most is no longer a person at a console. It is the automation account, the token in the pipeline and the runner that holds them. This guide covers how to scope, store, approve and monitor those non-human identities. It is written for network automation engineers, platform teams and the security architects who review NetDevOps designs, and it goes deeper than our device-level guides on the automation layer itself.

Key takeaways

• The automation account is the most privileged identity on the network. It usually reaches every device with write rights, so treat it like a domain administrator, not like a monitoring login.
• Split read, plan and push identities. Collectors, validation jobs and the push stage each get their own credential, and only the push stage can write.
• Use the protocol's own authorisation. NETCONF and RESTCONF servers that implement the NETCONF Access Control Model (RFC 8341) let you restrict automation users to specific modules, paths and operations.
• Gate pushes in the pipeline, not in the playbook. Protected branches, required reviewers and secrets that are released only after approval stop one compromised commit from reaching production devices.
• Watch the automation path for drift. Changes made outside the pipeline, pushes outside change windows and tokens used from new addresses are the signals that matter.

Where network automation credentials live

A typical NetDevOps estate has five places where credentials accumulate. Each is a non-human identity with its own owner, scope and lifecycle, and each needs to appear in your inventory.

The source of truth is easy to overlook. If the pipeline renders configuration from it, write access to the source of truth is effectively write access to the network one run later. Protect its tokens with the same care as device credentials.

Designing automation identities

The single shared "netops" account with privilege 15 everywhere is the pattern to retire. Our recommended model separates identities by stage and by blast radius.

• Collector identity: read-only on devices and the source of truth. Used by backup, compliance and drift jobs. It still reads configuration that can contain secrets, so store its output as sensitive. See the Network Configuration Backup and Change Control guide for how to protect the configuration archive.
• Validation identity: read-only, used by dry runs, check mode and pre-change tests. It never needs write rights, so a compromised merge request cannot change devices during planning.
• Push identity: write rights, available only to the deployment stage after approval. Split it by domain where your scale allows: one for campus, one for data centre, one for WAN edge, so a compromise does not reach the whole estate.
• Controller service accounts: one per integration, with the narrowest role the controller offers, never a shared administrator.
• Break-glass local accounts: kept for loss of AAA only, excluded from automation, and rotated after each use. See the Break-Glass Account Guide.

Authenticate automation accounts through your central AAA service rather than local device accounts, so you can disable one identity everywhere and see every login in one log. The joint CISA, NSA, FBI and international partner guidance on communications infrastructure (December 2024) recommends centralised AAA, least privilege through role-based access, regular account review and limited session durations for device administration. Apply the same rules to automation identities.

Choosing a credential type

For key handling, see the SSH Key Management Guide and the SSH Protocol and Certificate Authority Guide. For the secrets manager side, see the Secrets Management Guide.

Securing model-driven interfaces: NETCONF, RESTCONF and NACM

Model-driven interfaces give you finer control than the command line, but only if you configure it.

• Transport: NETCONF over SSH uses TCP port 830 and the SSH subsystem name "netconf" (RFC 6242). RESTCONF must run over TLS on the "https" scheme, default port 443, and the RFC states it must not be used over HTTP without TLS (RFC 8040). Restrict both ports to the management network and the automation runners with access control lists.
• Client authentication: RFC 8040 says RESTCONF servers should require TLS client certificates and may fall back to HTTP authentication. The authenticated identity becomes the username that access control rules evaluate.
• Server validation: RESTCONF clients must validate the server certificate path or match a pinned certificate, and terminate the connection if neither succeeds. Make sure your automation libraries do not have verification switched off "for the lab" in production.

Using NACM to scope automation users

The NETCONF Access Control Model, RFC 8341 (Standards Track, March 2018), defines groups, rule-lists and rules that permit or deny create, read, update, delete and exec on modules, protocol operations, notifications and data paths. Rules are evaluated in order and the first match wins. The defaults matter:

Two limits are worth knowing. NACM does not control local or remote files or datastores reached through a url parameter, and an implementation may offer a recovery session that bypasses enforcement. Protect and monitor that recovery path as you would a break-glass account. Confirm how your platform implements NACM and recovery in the vendor's documentation, because support varies.

Protecting the source of truth and controller APIs

API tokens for the source of truth and for controllers are the credentials most often pasted into scripts. Use each product's own controls. NetBox is a useful example because its documentation is explicit:

• Read-only by default where possible: NetBox tokens have a write option; leave it off for collectors so the token is limited to read operations.
• Expiry: set an expiry time on tokens issued to external or temporary clients.
• Allowed IPs: restrict tokens to the runner subnets. NetBox rejects authentication from addresses outside the allowed ranges, and it determines the client address from configured headers, so check that your proxy sets them correctly.
• Token version: NetBox documents v2 tokens (introduced in v4.5) as the recommended type, hashed with a pepper so the plaintext is not stored on the server. Its docs describe v1 tokens as deprecated from v4.6 and due for removal in v5.0. Plan the move and confirm the current schedule in the NetBox documentation.
• Who can mint tokens: by default NetBox users can create their own tokens; the users.grant_token permission allows creating tokens for others and should sit with very few people.
• Apply vendor security updates promptly: follow the product's release notes and advisories, and rotate tokens when a release note tells you to.

For vendor controllers, create one service account per integration with the narrowest role, record an owner, and route API access through the management network. The SD-WAN Security Guide covers controller-level design for wide area networks.

Gating pushes in the pipeline

The pipeline is the control point between a commit and a live device. Design it so that no single person, token or runner can push alone.

1. Protect the branch that deploys. Only merges to a protected branch reach the push stage. Require review on merge.
2. Use a deployment environment with approval. In GitHub Actions, environments support up to six required reviewers, a "prevent self-review" option so the person who triggered the deployment cannot approve it, wait timers, and restrictions on which branches and tags can deploy. Environment secrets are not released to a job until a reviewer approves. GitLab and other platforms offer equivalent protected environments: use whichever your team runs.
3. Keep push credentials in the environment, not the repository. Only the approved deployment job can read them. Validation jobs get the read-only identity.
4. Run a dry run first. Check mode or a candidate configuration diff, attached to the approval, so the reviewer approves a concrete change.
5. Use commit-confirmed or rollback where the platform supports it. A change that loses management access reverts itself.
6. Record the change. Pipeline run ID, commit, approver and device list go to the change record. See the Change Management Security guide.

Self-hosted runners that sit on the management network are high-value targets: dedicate them to network jobs, do not let untrusted branches run on them, and rebuild them regularly. See the Self-hosted CI/CD Runners and Build Agents guide and the CI/CD Pipeline Identity Security Guide. Where Ansible is the push tool, the Ansible and AWX Security Guide covers credential types and execution environments; note that ansible-vault rekey changes the vault password, not the secret inside, and older copies encrypted with the old vault password stay readable with it, so (our recommendation) rotate the underlying device credential, not just the vault key.

Decision guidance

Detection and measurement

Log the automation path end to end and correlate it with device AAA logs.

• Logins by automation accounts from outside runner subnets: any such login is a credential leak until proven otherwise.
• Configuration changes without a pipeline run: the CISA guidance asks teams to investigate any change made outside change management. Compare device change events with pipeline run IDs.
• Pushes outside change windows or without an approver: alert from the CI/CD audit log.
• Token use from new addresses or after long idle periods: source of truth and controller audit logs show last-used time.
• Changes to AAA, NACM or logging settings: a write to enable-nacm, AAA servers or syslog destinations is high severity. See the Network Device Syslog and Configuration Change Detection Guide.

Metrics that show the programme is working:

• Percentage of device changes made through the pipeline (target: above 95 percent outside emergencies).
• Number of automation credentials with write rights, and the number of devices each can reach.
• Median age of automation credentials and tokens, against your rotation standard.
• Percentage of push runs with a recorded approver who was not the author.
• Out-of-pipeline changes detected per month, and time to reconcile each.

Implementation roadmap

1. Inventory (weeks 1 to 2): list every automation account, token and key across devices, AAA, the source of truth, controllers and runners, with owner and scope.
2. Split identities (weeks 3 to 6): create read and push identities in AAA, move collectors to read-only, and pilot on one device group. Keep the old shared account disabled but present for two weeks as a rollback path, then delete it.
3. Move secrets (weeks 4 to 8): fetch credentials from a secrets manager at run time and remove passwords from repositories and runner disks.
4. Gate the pipeline (weeks 6 to 10): protected environment, approval, dry run attached, push secrets only in the environment.
5. Scope model-driven access (weeks 8 to 14): NACM rule-lists for automation groups on platforms that support them; test in a lab first, because a wrong rule can lock out the push identity.
6. Detect and review (ongoing): alerts above, quarterly review of automation identities. See How to Run an Access Review for Service Accounts.

Framework mapping

Common failure patterns

• One shared automation account with full rights everywhere: no attribution, no way to disable it without stopping all automation, and every runner holds it.
• Write tokens for read jobs: backup and compliance jobs given write tokens because "it was easier", turning a monitoring compromise into a change capability.
• Source of truth treated as documentation: broad token creation rights and no audit, while the pipeline trusts whatever it says.
• Certificate verification disabled in automation libraries: a lab shortcut that survives into production and allows interception of device credentials.
• Vault rekey mistaken for rotation: the vault password changes but the device password inside does not, so old copies remain useful.
• Runners on the management network running untrusted branches: any contributor's pull request can reach the devices.

Practitioner checklist

• Inventory every automation account, token and key, with an owner and the devices it can reach.
• Separate collector, validation and push identities, and authenticate them through central AAA.
• Fetch device credentials from a secrets manager at run time; remove them from repositories and runner disks.
• Release push credentials only to an approved deployment job, with self-review prevented.
• Restrict NETCONF (port 830) and RESTCONF (443) to runner subnets, with certificate validation on.
• Configure NACM rule-lists for automation groups where supported, and alert on changes to enable-nacm.
• Use read-only, IP-restricted, expiring tokens on the source of truth and controllers.
• Alert on configuration changes without a matching pipeline run and on automation logins from unexpected sources.
• Review automation identities quarterly and rotate after staff or vendor changes.

Standards and references

• IETF: RFC 8341 Network Configuration Access Control Model
• IETF: RFC 8040 RESTCONF Protocol
• IETF: RFC 6242 Using the NETCONF Protocol over Secure Shell (SSH)
• CISA: Enhanced Visibility and Hardening Guidance for Communications Infrastructure
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NetBox Labs: NetBox REST API and API tokens
• GitHub Docs: Deployments and environments
• Ansible Documentation: Build your inventory (network automation)

Related NHI Mgmt Group resources: Network Device Management Plane Hardening Guide, Ansible and AWX Security Guide, Network Configuration Backup and Change Control, NHI lifecycle automation.