Chapter Nine
Secrets — Ansible Vault
The Larkspur database password lives in git — but as an AES-256 blob, not plaintext. Ansible Vault encrypts the secrets your playbooks need, decrypts them in memory for the length of a run, and writes nothing back to the node. This chapter covers the Vault CLI, the vault.yml split pattern, supplying the key in CI, when an external manager earns its weight, and the leak channels no_log exists to close.
Every other configuration-management course eventually hits the same wall: the playbook needs a database password, an API key, a TLS private key — and those values cannot sit in plaintext in a git repo anyone can clone. Ansible's answer is Vault, symmetric AES-256 encryption built straight into ansible-core. You encrypt the secret with a passphrase, commit the ciphertext, and Ansible decrypts it in memory at run time using the key you supply. There is no separate vault server to run for the basic case, and there is no state file to leak the secret into the way a provisioning tool would.
This is where the Larkspur web stack stops storing vault_db_password in the clear. Across these five topics the secret moves into an encrypted vault.yml, gets supplied to a CI run without a human typing it, and is guarded against leaking through verbose output or a process table. The spine holds throughout: nothing decrypted persists on the node beyond what your own tasks deliberately write, because the encrypted file in git is the only place the secret lives at rest.