Why Vault?

Ansible Vault is used to encrypt and protect sensitive data—such as passwords, API keys, and certificates—so they are never exposed in plain text inside your automation code.

Ansible Vault is safer than environment variables because it securely binds encrypted secrets directly to your automation code. While environment variables are temporary, exposed to unauthorized system processes, and easily leaked in logs, Ansible Vault allows you to safely commit protected data directly into Git. This keeps your credentials secure, version-controlled, and accessible only in memory during runtime.

The Problem With The env Lookup For Real Secrets

Three genuine gaps, all traceable directly back to that chapter:

1. Control-node only, and it assumes the secret is already there somehow. Lookups run on the control node, always — which means an env-sourced secret has to already be exported there, manually or via some separately-managed file. It doesn’t solve how the secret actually gets distributed to everyone who needs to run the playbook; it just assumes that problem is already solved elsewhere.
2. Completely unencrypted. Wherever that secret actually lives before it’s exported — a .env file, a shell profile — it’s sitting there in plain text. Accidentally committed to git, or exposed by a compromised machine, it’s trivially readable.
3. Nothing to actually check into version control. The whole point of keeping playbooks and roles in git is a single, reproducible source of truth. An env-based secret can never be part of that repo at all — committing it would defeat the entire purpose — which means your “reproducible” project is quietly missing a piece that lives only in someone’s head or a separately-managed, unversioned file.

What Vault Actually Does

Ansible Vault encrypts sensitive data — a whole file, or a single value — using a password. The encrypted result is genuinely safe to commit directly into version control alongside everything else, since without the password, it’s unreadable. At runtime, when the playbook actually runs, you supply the password, and Ansible decrypts the content in memory just long enough to use it — the plaintext secret is never written back to disk unencrypted, unless you deliberately choose to.

The Core Workflow, At A Glance

Encrypt a file or value with a password. Commit the encrypted version to your repository. Whoever needs to run the playbook supplies the same password at runtime. Ansible decrypts transparently, and the playbook proceeds exactly as if the values had always been ordinary variables.

Why Not Just… Not Commit Secrets At All?

This is a legitimate alternative in some setups — secrets injected by a CI/CD pipeline, or a dedicated external secrets manager (worth noting: HashiCorp also has a product literally named “Vault,” an unrelated tool that happens to share the name — don’t confuse the two).

Ansible Vault’s real advantage over that approach is that the secret genuinely lives in your repository, versioned alongside everything that uses it — anyone with the password can reproduce the whole deployment from a clean clone, with nothing extra to separately track down or lose. It’s a different tradeoff, appropriate for different situations; both approaches are legitimate, and this course focuses on the one that fits directly into what you’ve already built throughout it.

Best Practices

• Reach for Vault, not env, the moment a secret needs to genuinely live in your version-controlled repository.
• Understand this workflow — encrypt, commit, decrypt at runtime with a password — before diving into the specific commands, which start with the very next chapter.