Ansible Automation Ansible Vault and Secrets Management 2 — Questions and Answers
Question 1: What encryption algorithm does Ansible Vault use by default?
- AES-256 (specifically AES256-CTR with PBKDF2 key derivation) (Correct answer)
- RSA-2048
- 3DES
- ChaCha20-Poly1305
Correct answer: AES-256 (specifically AES256-CTR with PBKDF2 key derivation)
Ansible Vault uses AES-256 encryption (AES256-CTR mode) with PBKDF2 for key derivation from the vault password.
Ansible Vault uses AES-256 in CTR (Counter) mode with PBKDF2 (Password-Based Key Derivation Function 2) to derive the encryption key from the vault password. The format header '$ANSIBLE_VAULT;1.1;AES256' indicates the vault format version and cipher. PBKDF2 adds resistance against brute-force attacks by making password hashing computationally expensive. The salt is randomly generated per encryption operation, ensuring identical files encrypted with the same password produce different ciphertext.
Question 2: How can you view the contents of an Ansible Vault-encrypted file without decrypting it permanently?
- ansible-vault view secrets.yml (Correct answer)
- ansible-vault read secrets.yml
- ansible-vault cat secrets.yml
- ansible-vault show secrets.yml
Correct answer: ansible-vault view secrets.yml
'ansible-vault view' decrypts and displays the file contents to stdout without writing the decrypted file to disk.
'ansible-vault view secrets.yml' prompts for the vault password and displays the decrypted content in your pager (usually 'less'). The file on disk remains encrypted. This is the safe way to inspect vault content without creating plaintext copies. Similarly, 'ansible-vault edit secrets.yml' opens the decrypted file in your editor and re-encrypts on save, without ever creating a persistent plaintext file on disk.
Question 3: What best practice should be followed when storing Ansible Vault password files on disk?
- The password file should have restricted permissions (mode 0600), be owned by the ansible user, and never be committed to version control (Correct answer)
- The password file should be stored in the playbook directory for easy access
- The password file should be encrypted with GPG for double encryption
- The password file should be stored in /etc/ansible/ with world-readable permissions
Correct answer: The password file should have restricted permissions (mode 0600), be owned by the ansible user, and never be committed to version control
Vault password files must be protected with strict file permissions and should never be stored in version-controlled directories.
Vault password file security best practices: 1. Set permissions to 0600 (read/write by owner only): 'chmod 600 .vault-password' 2. Own it by the Ansible service account 3. Add to .gitignore to prevent accidental commits 4. Store outside the project directory (e.g., ~/.vault-password) 5. Consider using a secrets manager (HashiCorp Vault, AWS SSM) to provide the password dynamically 6. In CI/CD, inject the password via environment variables rather than files on disk The vault password file path is configured via 'vault_password_file' in ansible.cfg.
Question 4: Which Ansible Vault command permanently decrypts a vault-encrypted file to plaintext?
- ansible-vault decrypt secrets.yml (Correct answer)
- ansible-vault remove secrets.yml
- ansible-vault unprotect secrets.yml
- ansible-vault plaintext secrets.yml
Correct answer: ansible-vault decrypt secrets.yml
'ansible-vault decrypt' decrypts the file in-place, converting it to plaintext YAML on disk—use with caution.
'ansible-vault decrypt secrets.yml' permanently decrypts the file and overwrites it with plaintext content. This should be used carefully as the file on disk is no longer protected. Common use cases: migrating to a new encryption scheme, debugging, or preparing for a major restructure. The operation requires the current vault password. After decryption, the file is a normal YAML file—remember to re-encrypt or use 'ansible-vault encrypt' before committing to version control.
Question 5: How do you integrate Ansible Vault with an external secrets manager like HashiCorp Vault?
- Use a vault password script that retrieves the password from HashiCorp Vault at runtime via its API (Correct answer)
- Ansible has native HashiCorp Vault integration via the 'hashicorp_vault' module
- Use the 'community.hashi_vault' lookup plugin to fetch secrets directly without Ansible Vault
- Configure the VAULT_ADDR environment variable and Ansible will automatically connect
Correct answer: Use a vault password script that retrieves the password from HashiCorp Vault at runtime via its API
A vault password script dynamically retrieves the Ansible Vault password from HashiCorp Vault at playbook runtime, combining both secret management systems.
Two common integration approaches: 1. Password script: Create an executable script that fetches the Ansible Vault password from HashiCorp Vault's API. Pass it with '--vault-password-file ./get-vault-password.sh'. Ansible executes the script and uses its stdout as the vault password. 2. Direct lookup (preferred for modern setups): Use 'community.hashi_vault' collection's lookup plugin to fetch secrets directly from HashiCorp Vault without Ansible Vault encryption: vars: db_password: "{{ lookup('community.hashi_vault.hashi_vault', 'secret=secret/db password') }}" The direct lookup approach eliminates Ansible Vault entirely when HashiCorp Vault is available.
Question 6: What does the 'no_log: true' directive do in an Ansible task?
- It prevents task arguments and output from being logged to stdout and Ansible log files, protecting sensitive data (Correct answer)
- It disables system logging on the managed host for the duration of the task
- It prevents the task from writing to syslog on the control node
- It suppresses all output including errors and failures
Correct answer: It prevents task arguments and output from being logged to stdout and Ansible log files, protecting sensitive data
'no_log: true' prevents sensitive task parameters (like passwords) from appearing in Ansible's verbose output and log files.
'no_log: true' is a task-level directive that suppresses all output from a task: - name: Set database password mysql_user: name: app_user password: "{{ db_password }}" state: present no_log: true Without 'no_log', verbose mode (-v) would display all module arguments including the password. With 'no_log: true', Ansible replaces all output from that task with 'censored'. This should be used for any task that handles passwords, tokens, keys, or other sensitive credentials. It works regardless of verbosity level.
Ansible Automation Ansible Vault and Secrets Management 2
What encryption algorithm does Ansible Vault use by default?