Automation shrinks change windows, but storing plain-text credentials in playbooks can undo every security win. Ansible Vault solves that problem with lightweight, AES-256 encryption baked straight into the Ansible CLI.
As a Network Automation Engineer, I've seen firsthand how automation can significantly reduce operational overhead and human error. Among all tools, Ansible stands out for its simplicity and agentless design, particularly valuable in automating network configurations across multivendor environments.
However, with great automation comes great responsibility — especially when handling device credentials and secrets. Storing plain-text passwords in playbooks or inventory files is a security risk you can’t afford. That’s where Ansible Vault comes in.
In this guide, I’ll walk you through securing your network automation projects using Ansible Vault, covering everything from basics to real-world examples for Cisco device management.
Table of contentsAnsible Vault is a built-in feature that encrypts sensitive data: passwords, API tokens, SSH keys, even entire config files. It uses strong AES-256 encryption to protect your secrets. By encrypting this sensitive info, Ansible Vault lets you:
Ansible Vault hooks right into the ansible-vault command-line utility. Here are the key things you'll do with it:
| Operation | Command |
|---|---|
| Create an encrypted file | ansible-vault create <filename> |
| Edit an encrypted file | ansible-vault edit <filename> |
| Encrypt an existing file | ansible-vault encrypt <filename> |
| Decrypt a file | ansible-vault decrypt <filename> |
| View contents of encrypted file | ansible-vault view <filename> |
| Re-key (change password) | ansible-vault rekey <filename> |
To encrypt a single variable like a Cisco device password and paste it into an inventory or variable file:
ansible-vault encrypt_string 'Cisco123!' --name 'ansible_password'Output:
ansible_password: !vault |
$ANSIBLE_VAULT;1.1;AES256
3238656332383764626231343234633666666330623730653232353737633162
3464323633626437373432386135636564663866313532390a38643063353866
3266636134323933653562333661663433666639666630353331636431383033
3736Paste the above in group_vars/all/vault.yml or inside the inventory variable section.
If you're unsure what a variable contains, but don't want to decrypt the whole file:
Option 1: Use ansible-vault view
ansible-vault view group_vars/all/vault.ymlThe mirrored command ansible-vault decrypt_string does the reverse of encrypt_string. It is really handy when you only need to reveal a single value for troubleshooting.
Option 2: Use ansible-vault decrypt temporarily
ansible-vault decrypt group_vars/all/vault.yml
ansible-vault encrypt group_vars/all/vault.yml # Re-encryptUse this when you want to rotate your vault password for a file (security best practice):
ansible-vault rekey group_vars/all/vault.ymlYou will be prompted for the old password and then asked to enter the new one.
Let’s say you have the following plain-text file creds.yml:
ansible_user: admin
ansible_password: Cisco123!
ansible_become_password: Enable456!To encrypt this securely:
ansible-vault encrypt creds.ymlAfter encryption, trying to open it will show garbled encrypted text unless accessed via vault commands.
Tip: Pull once, lock once
Automate secret retrieval from AWS Secrets Manager (or HashiCorp Vault) and encrypt it in-flight:
ansible_password: >-
You can test these kinds of patterns instantly inside a CloudMyLab Ansible Instant Environment sandbox, validating your secret retrieval and encryption logic without complex local setups or risking production.
For bigger projects or environments with different security levels (like dev vs. production), you might want to keep secrets in separate vault files, each with its own password.
Say you have:
You can encrypt each with a distinct password, giving it a unique ID.
ansible-vault encrypt --vault-id dev@prompt vault-dev.yml
ansible-vault encrypt --vault-id prod@prompt vault-prod.ymlAnd run your playbook like:
ansible-playbook site.yml --vault-id dev@prompt --vault-id prod@promptTired of --ask-vault-pass prompts? You may create Ansible vault password files. Store the password in a root-readable file and point Ansible at it or export an environment variable for CI runs.
Create a file (e.g., vault-pass.txt) with only the vault password inside.
echo 'MyStrongPassword123!' > vault-pass.txt
chmod 600 vault-pass.txtansible-playbook playbook.yml --vault-password-file vault-pass.txtMake sure vault-pass.txt is added to .gitignore and not pushed to source control!
Need a temporary enable password during a maintenance window? Prompt the user and encrypt on the fly. The value is stored encrypted in memory—never in plain text.
vars_prompt:
- name: "temp_enable_pass"
prompt: "Enter one-time enable password"
private: yes
encrypt: "ansible-vault"If you prefer not to store passwords anywhere:
ansible-playbook playbook.yml --ask-vault-passYou’ll be prompted securely at runtime.
Network teams back up running-configs daily. Keep those backups encrypted end-to-end.
- name: Encrypt running-configs
ansible.builtin.shell: |
ansible-vault encrypt config_backups/.cfg
- name: Copy encrypted cfgs off-box
copy:
src: "config_backups/.cfg.vault"
dest: "/mnt/secure-backup/"Decrypt only when you need to restore:
ansible-vault decrypt /mnt/secure-backup/rtr1.cfg.vaultLet’s secure Cisco device credentials in an Ansible inventory and use them in a playbook.
Encrypt device credentials:
ansible-vault create group_vars/all/vault.ymlContent:
ansible_user: admin
ansible_password: Cisco123!
ansible_become_password: Enable456!Need to load secrets from any encrypted file? Just add
vars_files:
- vault.ymlto your playbook header and Ansible will decrypt it at runtime.
[core_switches]
10.10.10.1
10.10.10.2
[core_switches:vars]
ansible_connection=network_cli
ansible_network_os=ios
ansible_user=
ansible_password=
ansible_become=true
ansible_become_method=enable
ansible_become_password=---
- name: Backup running-config from Core Switches
hosts: core_switches
gather_facts: no
tasks:
- name: Fetch running-config
ios_config:
backup: yesUsing password prompt:
ansible-playbook -i inventory.ini playbook.yml --ask-vault-passOr using a file:
ansible-playbook -i inventory.ini playbook.yml --vault-password-file vault-pass.txt--vault-id for environment-specific secrets.ANSIBLE_VAULT_PASSWORD_FILE.no_log: true on any task that handles plaintext.ansible-vault rekey) on a schedule.group_vars, vars_files, and clean inventory structure for readability.no_log: true so plaintext never hits your logs.Read more: Ansible setup step-by-step
As network engineers transition deeper into infrastructure automation, securing credentials becomes a non-negotiable part of the workflow. Ansible Vault offers a robust yet flexible way to keep secrets safe while still benefiting from Git versioning, collaboration, and playbook reuse.
Whether you're rolling out configs to hundreds of routers, managing device passwords in live production, or securely backing up your network configurations, Vault helps you automate securely and responsibly. Mastering Ansible Vault is an essential skill for any network automation engineer aiming to build reliable, secure, and scalable automation solutions.
Automation shouldn’t be trial and error in a live production environment. This is where CloudMyLab bridges the gap, providing:
✔ Hands-on lab environments to test Ansible Automation Platform in real-world conditions.
✔ Proof of Concept labs to validate automation workflows before deployment.
✔ Enterprise-ready scalability without the need for costly on-premise infrastructure.
💡 Why risk automation errors in production when you can test in a safe, enterprise-grade sandbox?
🔹 Start your automation journey today with CloudMyLab’s Ansible lab environments.
🔹 Sign up for a free trial and take your automation strategies from theory to reality.
Here are some helpful resources for learning more about Ansible:
Save the password in a file (e.g., vault-pass.txt) with restricted permissions (chmod 600 vault-pass.txt) and use ansible-playbook --vault-password-file vault-pass.txt. For CI/CD, export the ANSIBLE_VAULT_PASSWORD_FILE environment variable.
You can put per-user YAML files under group_vars/db_users/ (if db_users is a group) and encrypt each file with Vault. In your role, you could then use lookups (e.g., lookup('vars', inventory_hostname + '_db_pass')) to fetch the specific password for each host.
Yes—create a new Credential Type that exposes vault_password as a field and reference it in job templates. AWX injects the variable so you can drop --ask-vault-pass entirely.
Yes. Ansible Automation Platform, including AWX, has native support for Ansible Vault. You create a "Credential Type" within AWX/AAP that exposes a field for the vault password, which is then securely injected at runtime.
Add it straight to a playbook header:
vars_files:
- vault.yml # decrypted at runtimeThere's no recovery mechanism if you lose your Ansible Vault password. The encrypted data can't be decrypted without it. You'd have to restore secrets from a secure backup or just regenerate them. This really highlights why you need to manage your vault passwords securely.
Ansible Vault only encrypts the contents of files. It doesn't encrypt filenames or directory structures. If filename secrecy is critical, you might need to combine Vault with other tools like git-crypt or sops.
Yes. Ansible Automation Platform (AAP), including AWX, has native support for Ansible Vault. You create a "Credential Type" within AWX/AAP that exposes a field for the vault password, which is then securely injected at runtime.