Credentials are utilized by Tower for authentication when launching jobs against machines, synchronizing with inventory sources, and importing project content from a version control system.
Note
Tower encrypts passwords and key information in the Tower database and never makes secret information visible via the API.
The encryption/decryption algorithm uses Electronic Code Book (ECB) as the mode of operation with AES-128 as the block cipher. The 128-bit AES key is derived from the SECRET_KEY
(found in the awx
settings). Specific, sensitive, Model fields in Tower are encrypted and include:
Credential: password, ssh_key_data, ssh_key_unlock, become_password, vault_password
UnifiedJob: start_args
Data is encrypted before it is saved to the database and is decrypted as is needed in Tower. The encryption/decryption process derives the AES-128 bit encryption key from <SECRET_KEY, field_name, primary_key>
where field_name
is the name of the Model field and primary_key
is the database primary key. Thus, if any attribute used in the key generation process changes, Tower fails to correctly decrypt the secret.
Note
The rules of encryption and decryption for Ansible Tower also apply to one field outside of credentials, the Unified Job start_args
field, which is used through the job
, ad_hoc_command
, and system_job
data types. Refer to Unified Job List API Endpoint in the Ansible Tower API Guide for more information.
The Credentials link, accessible from the button displays a list of all available credentials. It can be sorted and searched by Name, Description, or Type.
Credentials can also be managed from either the Teams link or the Users link from the Setup () menu. To manage credentials for teams, browse to the Teams tab and edit the appropriate team. To manage credentials for a user, browse to the Users tab and edit the appropriate user.
Credentials added to a Team are made available to all members of the team, whereas credentials added to a user are only available to that specific user by default.
Buttons located in the upper right corner of the Credentials screen provide the following actions:
Create a new credential by selecting the button.
Enter the appropriate details depending on the type of credential and select Save.
Machine credentials define ssh and user-level privilege escalation access for playbooks. They are used when submitting jobs to run playbooks on a remote host.
Machine credentials have several attributes that may be configured:
Username: The username to be used for SSH authenticatation.
Password: The actual password to be used for SSH authenticatation. This password can be stored encrypted in the Tower database, if entered. Alternatively, you can configure Tower to ask the user for the password when necessary by selecting “Ask at runtime?”. In these cases, a dialog opens when the job is launched, promoting the user to enter the password and password confirmation.
Private Key: The actual SSH Private Key to be used to authenticate the user via SSH. This key is stored encrypted in the Tower database.
Private Key Passphrase: If the SSH Private Key used is protected by a password, you can configure a Key Password for the private key. This password may be stored encrypted in the Tower database, if entered. Alternatively, you can configure Tower to ask the user for the password as necessary by selecting “Ask at runtime?”. In these cases, a dialog opens when the job is launched, prompting the user to enter the password and password confirmation.
Privilege Escalation: Specifies the type of escalation privilege to assign to specific users. This is equivalent to specifying the --become-method=BECOME_METHOD
parameter, where BECOME_METHOD
could be sudo | su | pbrun | pfexec
.
Privilege Escalation Username: The username to use with escalation privileges on the remote system.
Privilege Escalation Password: The actual password to be used to authenticate the user via the selected privilege escalation type on the remote system. This password may be stored encrypted in the Tower database, if entered. Alternatively, you may configure Tower to ask the user for the password when necessary by selecting “Ask at runtime?”. In these cases, a dialog opens when the job is launched, promoting the user to enter the password and password confirmation.
Note
Sudo Password must be used in combination with SSH passwords or SSH Private Keys, since Tower must first establish an authenticated SSH connection with the host prior to invoking sudo to change to the sudo user.
Vault Password: If your playbook uses Ansible Vault, add the Vault password to your credentials here. Alternatively, you may configure Tower to ask the user for the vault password when necessary by selecting “Ask at runtime?”. In these cases, a dialog opens when the job is launched, promoting the user to enter the password and password confirmation.
For more information about Ansible Vault, refer to: http://docs.ansible.com/playbooks_vault.html
Warning
Credentials which are used in Scheduled Jobs must not be configured as “Ask at runtime?”.
Used with Projects to clone and update local source code repositories from a remote revision control system such as Git, Subversion, or Mercurial.
Source Control credentials have several attributes that may be configured:
Note
Source Control credentials cannot be configured as “Ask at runtime?”.
Enables synchronization of cloud inventory with Amazon Web Services.
Traditional Amazon Web Services credentials consist of the AWS Access Key and Secret Key.
Ansible Tower version 2.4.0 introduced support for EC2 STS tokens (sometimes referred to as IAM STS credentials). Security Token Service (STS) is a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users. To learn more about the IAM/EC2 STS Token, refer to: http://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html
AWS credentials consist of:
AWS_ACCESS_KEY
AWS_SECRET_KEY
AWS_SECURITY_TOKEN
Enables synchronization of cloud inventory with Rackspace.
Rackspace credentials consist of the Rackspace Username and API Key.
Enables synchronization of inventory with VMware vCenter.
VMware credentials have several attributes that may be configured:
Note
If the VMware guest tools are not running on the instance, VMware inventory sync may not return an IP address for that instance.
Enables synchronization of cloud inventory with Google Compute Engine.
Google Compute Engine credentials have several attributes that may be configured:
Enables synchronization of cloud inventory with Windows Azure.
Microsoft Azure credentials have several attributes that may be configured:
Enables synchronization of cloud inventory with OpenStack.
OpenStack credentials have several attributes that may be configured:
If you are interested in using OpenStack Cloud Credentials, refer to Utilitzing Cloud Credentials for more information, including a sample playbook.