When using the Ansible Playbook to install Alfresco on Linux hosts, one of the main concerns raised by our users is about the handling of secrets like database credentials. Historically those secrets have been handled as standard variables defined globally, that have been very handy from the complexity point of view but unfortunately very fragile on a security-oriented perspective, especially for production enterprise environments.
Luckily Ansible provides Ansible Vault out of the box that can be used to encrypt variables within YAML files and/or enable full file encryption. With Vault the secret content is available only to users knowing the passphrase required to decrypt the file. It's very handy for anyone that is using version control tools like GIT for managing infrastructure with Ansible; encrypted secrets can be safely committed even to a public repository (given that the passphrase is not available there in any way).
We decided to move all the security-related variables in a dedicated secrets.yml file. Moving forward this is the only place where the playbook expects secrets needed to install Alfresco to be provided. The playbook will validate the presence of the mandatory secrets during every run.
To simplify the transition of existing ansible customers and the adoption of new ones, we provide a playbook dedicated to the first-time initialization of the secrets.yml file. This playbook can generate secure secrets and encrypt them using one of the two Ansible Vault encryption options: encrypted variables or encrypted files.
Encrypted variables are just variables defined in a YAML file for which only the value has been encrypted. The main advantage for choosing this option is that the structure of the file is kept as is and we can automatically add new secrets that future versions of the playbook may introduce. The major drawback is that there is no straightforward way to peek at the actual values of the secrets without Ansible.
With Encrypted files instead, the full payload of the file is encrypted and can be accessed for view or changes using the `ansible-vault edit` command that will open the decrypted file into the preferred editor and automatically re-encrypt every change made to it.
It also possible to skip using Ansible Vault if a supported third-party secret management tool is available, for example HashiCorp Vault, AWS Secrets, 1Password or CyberArk just to cite a few. In this case is sufficient to use the lookup plugin of the supported tool to retrieve dynamically secrets usually using a remote API.
If you want to learn more, you can dive in the Secrets management section of the Alfresco Ansible Playbook Documentation or attend the upcoming Tech Talk Live #138 on June 8.
