How do you handle credentials and secrets in network automation?
Show the answer
Say this first
Secrets never go into Git in plain text. In Ansible I encrypt them with Ansible Vault or pull them at run time from a secrets manager such as HashiCorp Vault. In CI they are protected, masked pipeline variables. Automation uses its own service accounts with least privilege, authenticated through TACACS+ or RADIUS so every change is logged against that account. If a secret leaks, I rotate it, because Git history keeps it.
Go deeper
Ansible Vault
ansible-vault create group_vars/all/vault.yml
ansible-vault encrypt_string 'S3cure.pass' --name 'vault_netops_password'
ansible-playbook site.yml --ask-vault-pass
ansible-playbook site.yml --vault-password-file ~/.vault_passA common pattern keeps vault_ variables in an encrypted file and refers to them from normal variables:
ansible_password: "{{ vault_netops_password }}". People can read the variable names in reviews without
seeing the values.
Other places secrets live
- Environment variables for scripts, set by the CI system or a wrapper, not hard-coded.
- Secrets managers (HashiCorp Vault, CyberArk, cloud key vaults) with short-lived credentials and audit logs.
- CI variables marked protected and masked so they only reach protected branches and never print in logs.
Accounts
- A separate account per automation system, not a shared admin login.
- Read-only accounts for collection jobs (backups, inventory).
- AAA accounting on, so the logs show which account changed what.
They will ask next
Someone committed a device password to the repo. What now?
Rotate the password first, everywhere it is used. Then remove it from the repo history (for example with
git filter-repo) and force everyone to re-clone, add a secret scanner to the pipeline, and move the value into Vault. Deleting the line in a new commit is not enough.
Traps
- Thinking a private repo is a safe place for passwords. Access spreads and history is forever.