Ansible Vault — Secrets Management

ansible1-7 gave every concern its own tidy, version-controlled home. But roles and playbooks are naturally full of exactly the values pipelines1-5 and crypto1-11 both already warned about — database passwords, API keys, private keys. This chapter is the mechanism that lets those values live in version control safely, following the rule those earlier chapters already established.

The Problem — Roles and Playbooks Are Full of Secrets

Database passwords, API keys, TLS private keys — all naturally want to live as ordinary Ansible variables, in exactly the same files ansible1-7 just organized. But pipelines1-5's own rule stands regardless of which tool is committing the file: a credential committed to git in plaintext is compromised forever, even if it's later removed, since git history retains it. Ansible Vault is the tool for encrypting exactly these values, so they can live safely in version control alongside everything else — encrypted, not absent.

Encrypting a Whole File

edit never writes the plaintext to disk at any point during the process — it decrypts into memory, opens your editor, and re-encrypts on save. An encrypted file on disk looks genuinely unreadable:

Safe to commit, safe to diff (though the diff itself is meaningless without the password), and structurally no different from any other file in the repository.

Encrypting a Single Variable — encrypt_string

This produces a small, self-contained encrypted block that can be pasted directly into an otherwise-plaintext vars file. Often preferable to encrypting the whole file: the rest of the file — variable names, structure, non-sensitive values — stays readable in a normal diff, with only the genuinely sensitive value itself hidden.

Providing the Vault Password to Run a Playbook

--ask-vault-pass prompts interactively; --vault-password-file points at a file (or an executable script that outputs the password) — the practical option for CI, where nothing can be typed interactively. Running a playbook that references encrypted variables without supplying the password fails cleanly, with a clear error — not a silent, wrong value quietly used instead.

Vault IDs — Multiple Passwords for Multiple Environments

A light touch, worth naming: vault IDs let genuinely different environments use genuinely different vault passwords. Someone who only has the dev password structurally cannot decrypt production secrets — a real, meaningful security boundary between environments, not just a naming convention.

Directly Extending pipelines1-5/crypto1-11's Own Rule

pipelines1-5 named "a committed credential is compromised forever" as the reason never to commit secrets in plaintext; crypto1-11 covered key management practice more broadly. Ansible Vault is the concrete mechanism that lets Ansible-managed secrets follow that exact rule while still living in version control the same way everything else in this course does — ansible1-7's own roles, and the same discipline tf1's own state-file material already applied to Terraform's own sensitive values.

Hands-On Exercises