Ansible Vault IDs organize secrets, but they do not rotate them
Ansible Vault encrypts sensitive variables and files. A vault ID labels which password was used to encrypt a piece of content, and the ID appears in the encrypted content header. It is a routing and operations convenience for environments that use more than one vault password. It is not a separate key derivation scheme and it does not automatically rotate the underlying data.
The distinction is practical. A vault ID can help a playbook select the dev, prod, or database password source. A label can also make logs and file names easier to understand. The password remains the secret that protects the content. If the password or client script is available to the wrong process, changing the label does not contain the exposure.
Keep password sources and labels separate
The Ansible documentation supports password files, prompts, and client scripts. A client script can retrieve a password from a keyring, database, or secret manager. The --vault-id option can pair a label with a source, such as dev@contrib-scripts/vault-keyring-client.py. The label itself is stored in plaintext and should be treated as metadata, not a secret.
Use one source of truth for each environment. Avoid a long list of ad hoc files on every workstation. Configure the pipeline to obtain the correct password for the target environment from a managed secret store, and keep a separate authorization for production decryption. A developer who can read test secrets should not automatically receive production vault access.
Do not place a vault password in a command line argument that appears in process lists or CI logs. Use a protected file, an interactive prompt, or a client script with a narrowly scoped credential. Protect the script itself as privileged code. It can read a secret manager token and return plaintext to Ansible, so its integrity matters as much as the encrypted file.
The encrypted variable's header makes the label visible. Keep labels stable and descriptive enough to support rotation, but avoid encoding user identities or ticket numbers that change frequently. A label that is tied to a temporary ticket can leave historical files with confusing metadata. A label such as prod-db should have a documented owner and a known set of consumers.
Remember what Vault protects
Ansible Vault encryption protects data at rest. Once Ansible decrypts a value for a task, the controller, target connection, task module, and logs may expose it. Review module arguments and debug output. Avoid printing a decrypted variable. Use no_log where the module supports it, and keep secrets out of inventory files, playbook defaults, and generated reports.
Encrypted values can also be copied into a container image, backup, or artifact package. A Vault file inside a public repository is still encrypted, but it may become a target for offline password guessing. Use a high-entropy password and a secret manager for the password source. Restrict access to the ciphertext as well, because an exposed encrypted file can be retained for later attack.
If a secret is written to disk by a playbook, file permissions and temporary directories matter. Set a restrictive umask on the controller and target, clean temporary files, and avoid world-readable backup directories. A secret that is encrypted in transit but stored in a world-readable temporary file has still leaked at rest on the endpoint.
Rotate the data, then the password
Changing a vault password with ansible-vault rekey changes the encryption of the selected file. It does not necessarily change the credentials stored inside the file. If the database password was exposed, rekeying the file without changing the database password leaves the credential valid. Rotate the external credential first or in a coordinated window, then re-encrypt the file with the new vault password.
Keep a dependency list for each vault ID. Find playbooks, templates, scheduled jobs, and operators that provide that ID. A password rotation that updates only one runner may leave another path with the old password and an outdated copy of the secret. Test the complete deployment path after rotation, including failure behavior when the old password is rejected.
Do not let fallback password selection become a blind retry loop. If a job can try the development, production, and database passwords in sequence, a mislabeled run may decrypt with an unintended key. Make the expected label explicit for the environment. Fail closed when the requested label or password source is missing, and log the label and source type without logging the password.
Ansible Vault is a useful part of secret handling when its operational model is clear. The team needs controlled password retrieval, encrypted content that is never casually decrypted into logs, and a rotation procedure that changes both the wrapper and the underlying credential. Vault IDs help organize that process. They cannot substitute for it.
Top comments (0)