Secure Secrets with Ansible Vault: Using Encrypted Files the Right Way

Hardcoding passwords in playbooks is one of those mistakes that feels harmless—until it isn’t. Whether it’s database credentials, API tokens, or SSH keys, secrets tend to creep into configuration files faster than we’d like.

This is exactly where Ansible Vault steps in. It lets you keep sensitive data encrypted while still making it usable within your automation workflows.

What Ansible Vault Actually Solves

Ansible playbooks are just YAML files. Easy to read, easy to version… and dangerously easy to leak secrets if you're not careful.

Ansible Vault allows you to:

• Encrypt entire files or specific variables
• Store secrets safely in version control
• Decrypt only at runtime when needed

So instead of this:

1db_password: supersecret123

You get an encrypted blob that looks like this:

1$ANSIBLE_VAULT;1.1;AES256
2613761663939633865623...

Not pretty—but very secure.

Encrypting Files with Ansible Vault

Let’s start with the most common workflow: encrypting a file that contains sensitive variables.

Create a file called secrets.yml:

1db_user: admin
2db_password: supersecret123

Now encrypt it:

1ansible-vault encrypt secrets.yml

You’ll be prompted to enter a password. Once encrypted, the file becomes unreadable without that password.

Using the Encrypted File in a Playbook

Ansible handles decryption automatically when you run a playbook:

1ansible-playbook site.yml --ask-vault-pass

Inside your playbook:

1- hosts: web
2  vars_files:
3    - secrets.yml
4
5  tasks:
6    - name: Connect to database
7      debug:
8        msg: "Using password {{ db_password }}"

The secret is decrypted at runtime, never exposed in plain text.

Working with Vault Passwords (Without Losing Your Mind)

Typing the vault password every time gets old quickly. Here’s where things get more practical.

Option 1: Use a Password File

1ansible-playbook site.yml --vault-password-file .vault_pass.txt

This file contains your vault password. Just make sure:

• It’s not committed to version control
• Permissions are restricted (chmod 600)

Option 2: Use Environment-Based Scripts

For teams, it’s common to use scripts that fetch vault passwords from secure stores like AWS Secrets Manager or HashiCorp Vault.

Example:

1ansible-playbook site.yml --vault-password-file ./get_vault_pass.sh

This keeps passwords out of both code and local files.

Encrypting Individual Variables Instead of Files

Sometimes encrypting an entire file is overkill. You might only need to protect a single value.

Here’s how:

1ansible-vault encrypt_string 'supersecret123' --name 'db_password'

This generates something like:

1db_password: !vault |
2          $ANSIBLE_VAULT;1.1;AES256
3          643937656234356...

You can paste that directly into your playbook or variable file.

Editing Encrypted Files Safely

Once a file is encrypted, you can’t just open it in your editor. Use:

1ansible-vault edit secrets.yml

This decrypts the file temporarily, lets you edit it, and re-encrypts it automatically when you exit.

Alternatively:

• ansible-vault view – read-only access
• ansible-vault decrypt – permanently decrypt (use cautiously)
• ansible-vault rekey – rotate encryption password

A Quick Real-World Setup

Let’s say you’re deploying a web app with database credentials.

Directory structure:

1project/
2  ├── site.yml
3  ├── group_vars/
4  │     └── all.yml
5  └── secrets.yml (encrypted)

secrets.yml (encrypted):

1db_password: supersecret123

group_vars/all.yml:

1db_user: appuser
2

site.yml:

1- hosts: app
2  vars_files:
3    - secrets.yml
4
5  tasks:
6    - name: Configure app
7      template:
8        src: config.j2
9        dest: /etc/app/config.conf

Secrets stay encrypted at rest but integrate seamlessly during execution.

Common Mistakes Developers Make

Here’s where things often go sideways:

• Committing unencrypted secrets first
  Even if you encrypt later, Git history still contains the plain text.
• Sharing vault passwords over Slack
  That defeats the purpose. Use secure channels or secret managers.
• Using one vault password for everything
  Better to segment by environment (dev, staging, prod).
• Forgetting access control
  Vault protects data, but not who can run playbooks.

Performance and Practical Considerations

Ansible Vault encryption is lightweight and doesn’t noticeably slow down most workflows. However:

• Large encrypted files can slightly impact parsing time
• Frequent decryption in CI pipelines should be optimized
• Use variable-level encryption if only a few secrets exist

In most real-world setups, the trade-off is well worth the security benefit.

When Ansible Vault Isn’t Enough

Ansible Vault is great for static secrets, but not ideal for dynamic or rotating credentials.

If you need:

• Automatic secret rotation
• Fine-grained access control
• Audit logs

Consider integrating external tools like:

• HashiCorp Vault
• AWS Secrets Manager
• Azure Key Vault

Ansible Vault still plays nicely alongside these systems.

Wrapping It Up

Ansible Vault isn’t flashy, but it’s one of the most practical tools for securing infrastructure code. It fits naturally into existing workflows, keeps secrets encrypted at rest, and avoids the chaos of managing sensitive data manually.

If your playbooks still contain plain-text credentials, fixing that is a high-impact, low-effort improvement. Vault gives you a straightforward way to do it right.