Answers: <p>Please read <a href="https://docs.ansible.com/ansible/2.4/vault.html" rel="nofollow noreferrer">https://docs.ansible.com/ansible/2.4/vault.html</a>
  Since Ansible 2.4 one could use <code>--vault-id @prompt</code>.</p>
  
  <p>Encrypt a file using ansible-vault:</p>
  
  <pre><code>ansible-vault encrypt /path/to/encrypted/file
  </code></pre>
  
  <p>Run the playbook and it will result in:</p>
  
  <pre><code>fatal: [localhost]: FAILED! =&gt; {"msg": "A vault password or secret must be
  specified to decrypt /path/to/encrypted/file"}
  </code></pre>
  
  <p>There are multiple options to decrypt files, including <code>@prompt</code>:</p>
  
  <pre><code>ansible-playbook some-playbook --vault-id @prompt
  </code></pre>
  
  <p>will prompt:</p>
  
  <pre><code>Vault password (default):
  </code></pre>
  
  <p>Once the vault password has been entered, the playbook should succeed.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-06T01:24:20.730Z
Answers: Reading the page it does look like there's a solution there, but unable to figure out using only the link. Could you please elaborate?
Answers: Vish
Answers: CC BY-SA 3.0
Answers: 2018-04-07T03:44:08.113Z
Answers: Thank you for elaborating. I'm indeed requiring asking the user for a vault password - using the older `--ask-vault-pass` option. And I fail to understand how replacing it with `--vault-id` would answer the bigger question of a better workflow.
Answers: Vish
Answers: CC BY-SA 3.0
Answers: 2018-04-07T03:45:26.937Z
Answers: When you referred me to the link I _did_ see one intriguing option: `ansible-playbook --vault-id my-vault-password.py`. I thought perhaps you had a solution around using a python script :) I'm also doing some thinking around this one.
Answers: Vish
Answers: CC BY-SA 3.0
Answers: 2018-04-05T22:14:38.443Z
Answers: 2018-04-06T17:49:29.857Z
Answers: 2018-04-06T17:49:29.857Z
Answers: 030
Answers: <h3>Vault password</h3>
  
  <p>First of all, you should get familiar with the fact that vault password file can be executable script. In this case Ansible executes it and expects to receive password as its output.</p>
  
  <p>For example you can use <code>gpg-agent</code> or <code>keychain</code> to store your actual password and unlock it when required. Read more in this blog post: <a href="https://benincosa.com/?p=3235" rel="noreferrer">https://benincosa.com/?p=3235</a></p>
  
  <p>If you are a bit paranoid, you can add notification when your password script is called, like this:</p>
  
  <pre><code>#!/bin/bash
  PARENT_PROCESS=$(ps -p $PPID -o args | tail -n 1)
  osascript -e "display notification \"Vault password used by ${PARENT_PROCESS}\" with title \"Ansible\" sound name \"default\""
  gpg --batch --use-agent --no-tty --decrypt key.gpg 2&gt;/dev/null
  </code></pre>
  
  <p>This vault password script uses <code>key.gpg</code> as actual vault key and also shows popup notification (for MacOS) with parent process name when script is used. Gpg-agent caches unlock password for some time, so there is no need to enter password every time you start playbook.</p>
  
  <p>Just set <code>vault_password_file = ./vault_pass.sh</code> in your <code>ansible.cfg</code>.</p>
  
  <h3>Environment</h3>
  
  <p>You said that you use <code>azure_rm.py</code> as dynamic inventory script. This means that you have to set credentials into your environment variables before you start ansible-playbook for it to be able to use them.</p>
  
  <p>You can make two files:</p>
  
  <p><code>secure_env</code> (encrypted with vault):</p>
  
  <pre><code>export AZURE_SECRET=xxx;export AZURE_SUBSCRIPTION_ID=xxx;
  </code></pre>
  
  <p><code>set_env</code> (plain text):</p>
  
  <pre><code>echo -n "Setting secure vars... "
  eval $(ansible-vault view secure_env)
  echo "done."
  </code></pre>
  
  <p>When you open new terminal to execute your automation tasks, you have to run:</p>
  
  <pre><code>source set_env
  </code></pre>
  
  <p>At this moment, bash evaluates <code>set_env</code> and <code>secure_env</code> (decrypted via ansible-vault). After this command you have Azure credentials defined for the current shell, so you can execute playbooks as usual:</p>
  
  <pre><code>ansible-playbook provision-my-azure-instances.yml
  </code></pre>
  
  <p>So using this two approaches, you can store <code>key.gpg</code> and <code>secure_env</code> in your repository; then in the new terminal call <code>source set_env</code> once, enter gpg password once (to unlock future use of key.gpg); then call <code>ansible-playbook</code> as many times as you like without any passwords.</p>
  
Answers: CC BY-SA 3.0
Answers: 2018-04-10T04:59:24.173Z
Answers: So the main advantage over my original approach is that it uses GPG - which brings up caching benefits --- right? The environment approach is similar to what I came up with.
Answers: Vish
Answers: CC BY-SA 3.0
Answers: 2018-04-10T05:52:14.727Z
Answers: From your OP I understand that you use wrapper every time when you run playbook. With `source` approach you set environment once per terminal session and can use all range of tools separately: ansible-playbooks, inventory scripts, azure cli, without any wrappers.
Answers: Konstantin Suvorov
Answers: CC BY-SA 4.0
Answers: 2019-01-30T07:18:42.543Z
Answers: Main benefit of using GPG (or a keychain on macOS or Linux) is that each team member has their own authentication to unlock a private key unique to them.  This key is then used to unlock the Ansible Vault password, which is a shared secret.  You have to rotate all your secrets if someone leaves the team anyway, including the Ansible Vault password, but at least the GPG/keychain passwords don't have to change.
Answers: RichVel
Answers: CC BY-SA 3.0
Answers: 2018-04-07T07:34:38.060Z
Answers: 2018-04-07T07:34:38.060Z
Answers: Konstantin Suvorov
Body: <h2>Background</h2>
  
  <ol>
  <li>We use Ansible to provision and manage Azure infrastructure. At the moment we run Ansible "manually" i.e. we <em>manually execute playbooks</em> for various automated tasks. No CI infrastructure.</li>
  <li>Probably not relevant but we manage our inventory using dynamic script <code>azure_rm.py</code>.</li>
  <li>We are encouraged to be as secure as possible i.e. 
  
  <ol>
  <li>Don't store Vault passwords in <code>~/.vault_pass</code> or in any local file</li>
  <li>Don't store Azure secrets in <code>~/.azure/credentials</code></li>
  <li>Don't store anything secure in <code>.bashrc</code>.</li>
  </ol></li>
  </ol>
  
  <p>In such a scenario, I am having trouble coming up with a coherent strategy to ensure that my playbooks can access Azure secrets, while following the guidelines above.</p>
  
  <h2>Question</h2>
  
  <p>How can I avoid storing Ansible Vault and Azure credentials on files, while still ensuring my playbooks can access them?</p>
  
  <h2>What I've tried</h2>
  
  <p>So far I have come up with a wrapper script that</p>
  
  <ol>
  <li>asks the user for Vault password</li>
  <li>Uses that to decrypt a Vaulted Shell script</li>
  <li>Evaluates the script, which loads Azure environment variables into the environment;</li>
  <li>Runs the playbook on the environment that has been thus set.</li>
  </ol>
  
  <p>Any better (more elegant, less complicated, more "Ansible") solutions out there?</p>
  
Comments: CC BY-SA 3.0
Comments: 2018-04-06T12:48:25.970Z
Comments: What bothers you most in this workflow?
Comments: Konstantin Suvorov
Comments: CC BY-SA 3.0
Comments: 2018-04-07T03:41:17.937Z
Comments: @KonstantinSuvorov mainly it's the number of hoops I need to jump to achieve what seems (to me at least) a fairly common requirement in compliance-heavy enterprises.
Comments: Vish
Tags: <ansible><ansible-vault>
Title: How do I run Ansible Azure playbooks while avoiding storing credentials in files?
UserDisplayName: Vish
ThreadText: # How do I run Ansible Azure playbooks while avoiding storing credentials in files?
  
  (Asked by: username_0 on 2018-04-04)
  
  ## Background
  
  1. We use Ansible to provision and manage Azure infrastructure. At the moment we run Ansible "manually" i.e. we *manually execute playbooks* for various automated tasks. No CI infrastructure.
  2. Probably not relevant but we manage our inventory using dynamic script `azure_rm.py`.
  3. We are encouraged to be as secure as possible i.e.
     1. Don't store Vault passwords in `~/.vault_pass` or in any local file
     2. Don't store Azure secrets in `~/.azure/credentials`
     3. Don't store anything secure in `.bashrc`.
  
  In such a scenario, I am having trouble coming up with a coherent strategy to ensure that my playbooks can access Azure secrets, while following the guidelines above.
  
  ## Question
  
  How can I avoid storing Ansible Vault and Azure credentials on files, while still ensuring my playbooks can access them?
  
  ## What I've tried
  
  So far I have come up with a wrapper script that
  
  1. asks the user for Vault password
  2. Uses that to decrypt a Vaulted Shell script
  3. Evaluates the script, which loads Azure environment variables into the environment;
  4. Runs the playbook on the environment that has been thus set.
  
  Any better (more elegant, less complicated, more "Ansible") solutions out there?
  
  **Tags:** ansible, ansible-vault
  
  > **Comments:**
  > **username_1**: What bothers you most in this workflow?  
  > **username_0**: @username_1 mainly it's the number of hoops I need to jump to achieve what seems (to me at least) a fairly common requirement in compliance-heavy enterprises.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2018-04-07. Score: 8 | Accepted answer
  
  ### Vault password
  
  First of all, you should get familiar with the fact that vault password file can be executable script. In this case Ansible executes it and expects to receive password as its output.
  
  For example you can use `gpg-agent` or `keychain` to store your actual password and unlock it when required. Read more in this blog post: <https://benincosa.com/?p=3235>
  
  If you are a bit paranoid, you can add notification when your password script is called, like this:
  
  ```
  #!/bin/bash
  PARENT_PROCESS=$(ps -p $PPID -o args | tail -n 1)
  osascript -e "display notification \"Vault password used by ${PARENT_PROCESS}\" with title \"Ansible\" sound name \"default\""
  gpg --batch --use-agent --no-tty --decrypt key.gpg 2>/dev/null
  
  ```
  
  This vault password script uses `key.gpg` as actual vault key and also shows popup notification (for MacOS) with parent process name when script is used. Gpg-agent caches unlock password for some time, so there is no need to enter password every time you start playbook.
  
  Just set `vault_password_file = ./vault_pass.sh` in your `ansible.cfg`.
  
  ### Environment
  
  You said that you use `azure_rm.py` as dynamic inventory script. This means that you have to set credentials into your environment variables before you start ansible-playbook for it to be able to use them.
  
  You can make two files:
  
  `secure_env` (encrypted with vault):
  
  ```
  export AZURE_SECRET=xxx;export AZURE_SUBSCRIPTION_ID=xxx;
  
  ```
  
  `set_env` (plain text):
  
  ```
  echo -n "Setting secure vars... "
  eval $(ansible-vault view secure_env)
  echo "done."
  
  ```
  
  When you open new terminal to execute your automation tasks, you have to run:
  
  ```
  source set_env
  
  ```
  
  At this moment, bash evaluates `set_env` and `secure_env` (decrypted via ansible-vault). After this command you have Azure credentials defined for the current shell, so you can execute playbooks as usual:
  
  ```
  ansible-playbook provision-my-azure-instances.yml
  
  ```
  
  So using this two approaches, you can store `key.gpg` and `secure_env` in your repository; then in the new terminal call `source set_env` once, enter gpg password once (to unlock future use of key.gpg); then call `ansible-playbook` as many times as you like without any passwords.
  
  > **Comments:**
  > **username_0**: So the main advantage over my original approach is that it uses GPG - which brings up caching benefits --- right? The environment approach is similar to what I came up with.  
  > **username_1**: From your OP I understand that you use wrapper every time when you run playbook. With `source` approach you set environment once per terminal session and can use all range of tools separately: ansible-playbooks, inventory scripts, azure cli, without any wrappers.  
  > **username_3**: Main benefit of using GPG (or a keychain on macOS or Linux) is that each team member has their own authentication to unlock a private key unique to them.  This key is then used to unlock the Ansible Vault password, which is a shared secret.  You have to rotate all your secrets if someone leaves the team anyway, including the Ansible Vault password, but at least the GPG/keychain passwords don't have to change.  
  
  ---
  
  ### Answer by username_2 on 2018-04-05. Score: 2
  
  Please read <https://docs.ansible.com/ansible/2.4/vault.html>
  Since Ansible 2.4 one could use `--vault-id @prompt`.
  
  Encrypt a file using ansible-vault:
  
  ```
  ansible-vault encrypt /path/to/encrypted/file
  
  ```
  
  Run the playbook and it will result in:
  
  ```
  fatal: [localhost]: FAILED! => {"msg": "A vault password or secret must be
  specified to decrypt /path/to/encrypted/file"}
  
  ```
  
  There are multiple options to decrypt files, including `@prompt`:
  
  ```
  ansible-playbook some-playbook --vault-id @prompt
  
  ```
  
  will prompt:
  
  ```
  Vault password (default):
  
  ```
  
  Once the vault password has been entered, the playbook should succeed.
  
  > **Comments:**
  > **username_0**: Reading the page it does look like there's a solution there, but unable to figure out using only the link. Could you please elaborate?  
  > **username_0**: Thank you for elaborating. I'm indeed requiring asking the user for a vault password - using the older `--ask-vault-pass` option. And I fail to understand how replacing it with `--vault-id` would answer the bigger question of a better workflow.  
  > **username_0**: When you referred me to the link I _did_ see one intriguing option: `ansible-playbook --vault-id my-vault-password.py`. I thought perhaps you had a solution around using a python script :) I'm also doing some thinking around this one.  
  
  ---
  
  