r/ansible
How do you prove an Ansible Vault password rotation reached every encrypted file and runner?
- upvotes
- 15
- comments
- 11
Post
Rekeying the obvious vault files is not enough if inventories, role defaults, old branches, CI variables, AWX credentials, or infrequently used playbooks still depend on the previous password. A successful run with the new credential proves one execution path works, but it does not show that the old credential is no longer required anywhere. What belongs in the rotation gate? I am considering inventorying every file with an Ansible Vault header, mapping each vault ID to its runners and repositories, rekeying into a reviewed commit, and testing representative playbooks in check mode and against disposable targets. CI and AWX would receive the new credential before the old one enters a short monitored fallback window, with any use of the old vault ID treated as a failure. Is there a dependable way to discover all encrypted files and credential references across collections and branches without exposing plaintext? How do you handle mixed vault IDs, offline operators, rollback, and proving the retired password can no longer decrypt any current secret?
Extracted from these lines
[comment u/sudonem] If this is the level of complexity you’re facing in your environment, it’s probably time to consider standing up Hashicorp Vault rather than relying on Ansible Vault files.
[comment u/sudonem] Secrets get updated in Hashicorp Vault and ALL playbooks / roles are immediately guaranteed to b
[comment u/darthfiber] A password vault is what you need to address this. That way nothing is stored in code, you can audit who used them, auto rotate them, and prevent them from ever persisting on a developers machine.