When running a job template against one or more remote hosts or nodes,
you need to create a credential and then associate it with your job template.
The default credential is machine,
but we have lots of different types of credentials.
An example of a machine credential is a SSH used in the admin password.
You can then delegate playbook‑related tasks to other teams without
giving them the actual passwords or the SSH keys.
I consider the credential object in Ansible Tower
to be a big win for governance.
Ansible Tower uses credentials for various types of authentication.
Some of the most common use of credentials are SSH
authentication for executing Ansible Playbooks,
synchronizing dynamic inventories,
and fetching Ansible Playbooks from a version control.
So you know that there are different types of credentials used to
authenticate to the different managed assets.
We know that machine credential is the default type,
and we have many different credentials that we use to
connect to the different managed assets.
Then we have Ansible Vault.
So Ansible Vault is a feature to keep sensitive data in encrypted form,
for example, passwords or keys,
instead of saving them as plain text in your roles or playbooks.
And Ansible Vault is a normal file on your disk that you can edit with
your favorite text editor with one key difference.
When you hit that Save button,
the file is locked inside a strong AES‑256 encryption.
And what I really like about these Vault files is that they
can be placed under source control and then distributed to
multiple locations securely.
The data files, such as the Ansible tasks,
handlers, arbitrary files, and even binary files can all be encrypted with Vault.
These are then decrypted at the destination on the target host.