HiveBrain v1.2.0
Get Started
← Back to all entries
snippetMinor

How do I run Ansible Azure playbooks while avoiding storing credentials in files?

Submitted by: @import:stackexchange-devops··
0
Viewed 0 times
whilestoringcredentialsazureplaybooksfileshowavoidingansiblerun

Problem

Background

  • 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.



  • Probably not relevant but we manage our inventory using dynamic script azure_rm.py.



  • We are encouraged to be as secure as possible i.e.



  • Don't store Vault passwords in ~/.vault_pass or in any local file



  • Don't store Azure secrets in ~/.azure/credentials



  • 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

  • asks the user for Vault password



  • Uses that to decrypt a Vaulted Shell script



  • Evaluates the script, which loads Azure environment variables into the environment;



  • Runs the playbook on the environment that has been thus set.



Any better (more elegant, less complicated, more "Ansible") solutions out there?

Solution

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.

Code Snippets

#!/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
export AZURE_SECRET=xxx;export AZURE_SUBSCRIPTION_ID=xxx;
echo -n "Setting secure vars... "
eval $(ansible-vault view secure_env)
echo "done."
source set_env
ansible-playbook provision-my-azure-instances.yml

Context

StackExchange DevOps Q#3806, answer score: 8

Revisions (0)

No revisions yet.