Secure Secrets with Ansible Vault Using Encrypted Strings

You’ve probably done this at least once: hardcoded a password into a playbook just to “get things working.” It works… until it doesn’t. Secrets leak, repos get shared, and suddenly that quick shortcut becomes a liability.

This is exactly where Ansible Vault encrypted strings shine. Instead of encrypting entire files, you can surgically protect only the sensitive values—keeping everything else readable and maintainable.

Why Encrypted Strings Instead of Full Vault Files?

Encrypting whole files with Ansible Vault is common, but it comes with trade-offs:

• Harder to review changes in version control
• Less readable for collaborators
• Forces decryption even when only one value is sensitive

Encrypted strings solve this neatly. You encrypt just the secret—like a password or API key—while keeping the rest of your YAML in plain text.

Think of it as field-level encryption instead of file-level encryption.

Creating an Encrypted String

Here’s the quickest way to generate an encrypted value:

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

You’ll be prompted for a Vault password, and the output will look something like this:

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

This snippet is ready to paste directly into your variables file.

Using Encrypted Strings in a Playbook

Let’s say you’re configuring a database service. Instead of exposing credentials, you embed the encrypted string:

1# vars.yml
2
3db_user: app_user
4
5db_password: !vault |
6          $ANSIBLE_VAULT;1.1;AES256
7          623365633866643762...
8

Then reference it like any normal variable:

1- name: Configure database
2  hosts: db_servers
3  vars_files:
4    - vars.yml
5
6  tasks:
7    - name: Set database password
8      mysql_user:
9        name: "{{ db_user }}"
10        password: "{{ db_password }}"
11        priv: '*.*:ALL'
12

Ansible handles decryption at runtime—as long as you provide the Vault password.

Running the Playbook Securely

To execute the playbook, you’ll need to supply the Vault password:

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

For automation environments, you can avoid prompts:

• Use --vault-password-file
• Integrate with secret managers (e.g., HashiCorp Vault, AWS Secrets Manager)

Here’s Where Things Get Interesting

Encrypted strings are especially useful in mixed-sensitivity files. For example:

1api_url: https://api.example.com
2api_timeout: 30
3
4api_key: !vault |
5          $ANSIBLE_VAULT;1.1;AES256
6          316462613939...
7

Only the API key is encrypted. Everything else remains readable and diff-friendly.

Common Mistakes Developers Make

• Encrypting too much: Not everything needs to be hidden. Overusing Vault reduces clarity.
• Committing vault passwords: This defeats the entire purpose—never store them in the repo.
• Forgetting rekeying: If a Vault password is compromised, you should re-encrypt secrets.

Rekeying Encrypted Data

If you need to change the Vault password:

1ansible-vault rekey vars.yml

This updates all encrypted content with a new password without exposing the underlying data.

Performance Considerations

Decryption happens at runtime, but the overhead is usually negligible unless:

• You have hundreds of encrypted values
• You’re running large-scale parallel playbooks

In most real-world setups, readability and security benefits outweigh the cost.

When Should You Use Encrypted Strings?

They’re a great fit when:

• You want readable config files with minimal secrecy
• Only a few variables are sensitive
• You care about clean Git diffs

For fully sensitive files (like credential bundles), full Vault encryption might still make more sense.

A Practical Pattern That Works Well

Many teams adopt this hybrid approach:

• Store general config in plain YAML
• Encrypt only secrets using encrypted strings
• Use environment-specific Vault passwords

This keeps things secure without turning your repo into an unreadable blob.

Final Thoughts

Ansible Vault encrypted strings hit a sweet spot between security and usability. You don’t have to choose between protecting secrets and keeping your playbooks understandable—you can have both.

If your current setup involves fully encrypted files or (worse) plaintext secrets, switching to encrypted strings is a small change that pays off quickly.