Ansible uses variables to manage differences between systems. With Ansible, you can execute tasks and playbooks on multiple different systems with a single command. To represent the variations among those different systems, you can create variables with standard YAML syntax, including lists and dictionaries. You can define these variables in your playbooks, in your inventory, in re-usable files or roles, or at the command line. You can also create variables during a playbook run by registering the return value or values of a task as a new variable.
After you create variables, either by defining them in a file, passing them at the command line, or registering the return value or values of a task as a new variable, you can use those variables in module arguments, in conditional “when” statements, in templates, and in loops. The ansible-examples github repository contains many examples of using variables in Ansible.
---------------------------------------------------COMMAND----------------------------------------------------------To Run Script- ansible-playbook 3rd.yaml
Ansible Vault is a feature of ansible that allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plaintext in playbooks or roles. These vault files can then be distributed or placed in source control.
To enable this feature, a command line tool - ansible-vault - is used to edit files, and a command line flag (--ask-vault-pass, --vault-password-file or --vault-id) is used. Alternately, you may specify the location of a password file or command Ansible to always prompt for the password in your ansible.cfg file. These options require no command line flag usage.
Ansible Vault can encrypt any structured data file used by Ansible.
This can include “group_vars/” or “host_vars/” inventory variables, variables loaded by “include_vars” or “vars_files”, or variable files passed on the ansible-playbook command line with -e@file.yml or -e@file.json. Role variables and defaults are also included.
Ansible tasks, handlers, and so on are also data so these can be encrypted with vault as well. To hide the names of variables that you’re using, you can encrypt the task files in their entirety.
Ansible Vault can also encrypt arbitrary files, even binary files. If a vault-encrypted file is given as the src argument to the copy, template, unarchive, script or assemble modules, the file will be placed at the destination on the target host decrypted (assuming a valid vault password is supplied when running the play).
Ansible also supports encrypting single values inside a YAML file, using the !vault tag to let YAML and Ansible know it uses special processing. This feature is covered in more detail below.
To create a new encrypted data file, run the following command:
ansible-vault create foo.yml
First you will be prompted for a password. After providing a password, the tool will launch whatever editor you have defined with $EDITOR, and defaults to vi. Once you are done with the editor session, the file will be saved as encrypted data.
The default cipher is AES (which is shared-secret based).
To create a new encrypted data file with the Vault ID ‘password1’ assigned to it and be prompted for the password, run:
To edit an encrypted file in place, use the ansible-vault edit command. This command will decrypt the file to a temporary file and allow you to edit the file, saving it back when done and removing the temporary file:
ansible-vault edit foo.yml
To edit a file encrypted with the ‘vault2’ password file and assigned the ‘pass2’ vault ID:
It is technically possible to separately encrypt files or strings with the same vault ID but different passwords, if different password files or prompted passwords are provided each time. This could be desirable if you use vault IDs as references to classes of passwords (rather than a single password) and you always know which specific password or file to use in context. However this may be an unnecessarily complex use-case. If two files are encrypted with the same vault ID but different passwords by accident, you can use the rekey command to fix the issue.
If you have existing files that you no longer want to keep encrypted, you can permanently decrypt them by running the ansible-vault decrypt command. This command will save them unencrypted to the disk, so be sure you do not want ansible-vault edit instead:
This method leaves the string in your shell history. Do not use it outside of testing.
Result:
Reading plaintext input from stdin. (ctrl-d to end input)db_password:!vault|$ANSIBLE_VAULT;1.2;AES256;dev613239313538666663363061393739373163663661386561313238633738663766663533643737613539633234313836346435323766306164626134376564330a373530313635343535343133316133366436663064346162663764343632393464336432383364646435663861353563343037363531366565633133366366360a3265663233633639366136646163646234373361306231333435303337393039
To be prompted for a string to encrypt, encrypt it, and give it the name ‘new_user_password’:
Since Ansible 2.4 the --vault-id can be used to indicate which vault ID (‘dev’, ‘prod’, ‘cloud’, etc) a password is for as well as how to source the password (prompt, a file path, etc).
By default the vault-id label is only a hint, any values encrypted with the password will be decrypted. The config option DEFAULT_VAULT_ID_MATCH can be set to require the vault id to match the vault ID used when the value was encrypted. This can reduce errors when different values are encrypted with different passwords.
For example, to use a password file dev-password for the vault-id ‘dev’:
The config option DEFAULT_VAULT_IDENTITY_LIST can be used to specify a default vault ID and password source so that the --vault-id cli option does not have to be specified every time.
By default the vault ID labels (dev, prod etc.) are only hints, Ansible will attempt to decrypt vault content with each password. The password with the same label as the encrypted data will be tried first, after that each vault secret will be tried in the order they were provided on the command line.
Where the encrypted data doesn’t have a label, or the label doesn’t match any of the provided labels, the passwords will be tried in the order they are specified.
In the above case, the ‘dev’ password will be tried first, then the ‘prod’ password for cases where Ansible doesn’t know which vault ID is used to encrypt something.
To add a vault ID label to the encrypted data use the --vault-id option with a label when encrypting the data.
The DEFAULT_VAULT_ID_MATCH config option can be set so that Ansible will only use the password with the same label as the encrypted data. This is more efficient and may be more predictable when multiple passwords are used.
When implementing a script to obtain a vault password it may be convenient to know which vault ID label was requested. For example a script loading passwords from a secret manager may want to use the vault ID label to pick either the ‘dev’ or ‘prod’ password.
Since Ansible 2.5 this is supported through the use of Client Scripts. A Client Script is an executable script with a name ending in -client. Client Scripts are used to obtain vault passwords in the same way as any other executable script. For example:
The difference is in the implementation of the script. Client Scripts are executed with a --vault-id option so they know which vault ID label was requested. So the above Ansible execution results in the below execution of the Client Script:
contrib/vault/vault-keyring-client.py --vault-id dev
contrib/vault/vault-keyring-client.py is an example of Client Script that loads passwords from the system keyring.
By default, Ansible uses PyCrypto to encrypt and decrypt vault files. If you have many encrypted files, decrypting them at startup may cause a perceptible delay. To speed this up, install the cryptography package:
A vault encrypted file is a UTF-8 encoded txt file.
The file format includes a newline terminated header.
For example:
$ANSIBLE_VAULT;1.1;AES256
or:
$ANSIBLE_VAULT;1.2;AES256;vault-id-label
The header contains the vault format id, the vault format version, the vault cipher, and a vault-id label (with format version 1.2), separated by semi-colons ‘;’
The first field $ANSIBLE_VAULT is the format id. Currently $ANSIBLE_VAULT is the only valid file format id. This is used to identify files that are vault encrypted (via vault.is_encrypted_file()).
The second field (1.X) is the vault format version. All supported versions of ansible will currently default to ‘1.1’ or ‘1.2’ if a labeled vault-id is supplied.
The ‘1.0’ format is supported for reading only (and will be converted automatically to the ‘1.1’ format on write). The format version is currently used as an exact string compare only (version numbers are not currently ‘compared’).
The third field (AES256) identifies the cipher algorithm used to encrypt the data. Currently, the only supported cipher is ‘AES256’. [vault format 1.0 used ‘AES’, but current code always uses ‘AES256’]
The fourth field (vault-id-label) identifies the vault-id label used to encrypt the data. For example using a vault-id of dev@prompt results in a vault-id-label of ‘dev’ being used.
Note: In the future, the header could change. Anything after the vault id and version can be considered to depend on the vault format version. This includes the cipher id, and any additional fields that could be after that.
The rest of the content of the file is the ‘vaulttext’. The vaulttext is a text armored version of the encrypted ciphertext. Each line will be 80 characters wide, except for the last line which may be shorter.
