You can imagine that some of the variables may need some protection.
There is a built-in mechanic to protect variable called ansible-vault
You can use it in two ways by default
With ansible-vault we can create symetric encrypted files ansible can work with. But let's do the learning with an example
PNAME="AnsibleVault"
PDIR="/etc/ansible/projects/vault_demo"
mkdir -p $PDIR
chmod 700 $PDIR
cd $PDIR
$PDIR/inventory
# ansible demo inventory for $PNAME
[vault_demo]
host1
$PDIR/ansible.cfg
# custom ansible $PNAME configuration
[defaults]
inventory = ./inventory
roles_path = ./roles
collections_paths = ./collections
remote_user = root
log_path = ./ansible.log
vault_password_file = ./vault_unlock
echo hideThis > $PDIR/vault_unlock
mkdir $PDIR/group_vars
ansible-vault create $PDIR/group_vars/vault_demo.yml
---
password: superSecretStuff...
...
cat vault_unlock
cat group_vars/vault_demo.yml
ansible-inventory --vars --list
Do you understand why I call it the ugly way? Explain it to me!
$PDIR/ansible.cfg
# custom ansible $PNAME configuration
[defaults]
inventory = ./inventory
roles_path = ./roles
collections_paths = ./collections
remote_user = root
log_path = ./ansible.log
# vault_password_file = ./vault_unlock
ansible-inventory --vars --list
ERROR! Attempting to decrypt but no vault secrets found
Okay, that's not what we expected. Maybe we did something wrong
ansible-inventory --help
ansible-inventory --vars --list --ask-vault-pass
Can you imagine why I don't like this way either?
If you read the documentation carefully, you will find out that inventory and group_vars may be executeables as well. Hmm, maybe this is the way it can get nicer!?
$PDIR/ansible.cfg
# custom ansible $PNAME configuration
[defaults]
inventory = ./inventory
roles_path = ./roles
collections_paths = ./collections
remote_user = root
log_path = ./ansible.log
vault_password_file = ./vault_unlock
This program is used to control the key management facility in various ways using a variety of subcommands.
$PDIR/vault_unlock
#!/bin/bash
NAME=vault
PW_CNT=$(keyctl search @u user $NAME 2>/dev/null | wc -l)
if [ $PW_CNT -lt 1 ]
then
read -s -p "Feed vault password: " PASS
keyctl add user $NAME "$PASS" @u >/dev/null 2>&1
echo
else
keyctl print $(keyctl search @u user $NAME 2>/dev/null)
fi
Make it executeable
chmod 700 $PDIR/vault_unlock
Now call it and feed the password
./vault_unlock
- Call it again, what happens?
- LogOut, LogIn again, call it, what happens?
- Where is it stored?
If you are root, you can access a system service that can store your passwords temporarily until next reboot.
This is used too for harddisk decryption during boot-up.
Problem is here, that newer FIPS enabled systems remove this password 5min after creation.
$PDIR/vault_unlock
#!/bin/bash
# with keyname as absolute script path we can use it in several projects
systemd-ask-password --keyname=$(realpath $0) --accept-cached
Make it executeable
chmod 700 $PDIR/vault_unlock
Now call it and feed the password
./vault_unlock
- Call it again, what happens?
- LogOut, LogIn again, call it, what happens?
- As root user, the password can be kept until reboot!
This works for the session until you logout. But it is super simple and works with all users, not only root on any system.
$PDIR/vault_unlock
#!/bin/bash
if [ "x" == "x$VAULT_PASS" ]
then
echo "Variable VAULT_PASS is not set, please feed it with:"
echo
echo "read -s -p 'Feed vault password: ' VAULT_PASS ; export VAULT_PASS=\$VAULT_PASS"
echo
exit
fi
echo $VAULT_PASS
Make it executeable
chmod 700 $PDIR/vault_unlock
Now call it and feed the password
./vault_unlock
- Call it again, what happens?
- LogOut, LogIn again, call it, what happens?
- Where is it stored?