10. Credentials¶

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.

You can grant users and teams the ability to use these credentials, without actually exposing the credential to the user. If you have a user move to a different team or leave the organization, you don’t have to re-key all of your systems just because that credential was available in Tower.

Note

Tower encrypts passwords and key information in the Tower database and never makes secret information visible via the API.

10.1. Understanding How Credentials Work¶

Ansible Tower uses SSH to connect to remote hosts (or the Windows equivalent). In order to pass the key from Tower to SSH, the key must be decrypted before it can be written a named pipe. Tower then uses that pipe to send the key to SSH (so that it is never written to disk).

If passwords are used, Ansible Tower handles those by responding directly to the password prompt and decrypting the password before writing it to the prompt.

The encryption/decryption algorithm uses a variation of Fernet: a symmetric encryption cipher utilizing AES-256 in CBC mode alongside a SHA-256 HMAC. The 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-256 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 assigned auto-incremented record ID. 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.

10.2. Getting Started with Credentials¶

The Credentials link, accessible from the Setting ( settings ) button, displays a list of all available Credentials. It can be sorted and searched by Name, Description, Type, or Owners.

Credentials - home with example credentials

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.

To help you get started, a Demo Credential has been created for your use.

Clicking on the link for the Demo Credential takes you to the Details view of this Credential.

Credentials - home with demo credential details

Clicking on Permissions shows you users and teams associated with this Credential and their granted roles (owner, admin, auditor, etc.)

Credentials - home with permissions credential details

You can click the button to assign this Demo Credential to additional Users or Teams.

10.3. Add a New Credential¶

To create a new credential:

Click the button located in the upper right corner of the Credentials screen.

Create credential

Enter the name for your new credential in the Name field.
Optionally enter or select the name of the organization with which the credential is associated.
Enter or select the credential type you want to create.

Enter the appropriate details depending on the type of credential selected, as described in the following sections.
Click Save when done.

10.4. Credential Types¶

Topics:

Amazon Web Services
Google Compute Engine
Insights
Machine
Microsoft Azure Classic (Deprecated)
Microsoft Azure Resource Manager
Network
OpenStack
Red Hat CloudForms
Red Hat Satellite 6
Source Control
Vault
VMware vCenter

10.4.1. Amazon Web Services ¶

Selecting this credential type enables synchronization of cloud inventory with Amazon Web Services.

Credentials - create AWS credential

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_ID
AWS_SECRET_ACCESS_KEY
AWS_SECURITY_TOKEN

Note

If the value of your tags in EC2 contain booleans (yes/no/true/false), you must remember to quote them.

Warning

To use implicit IAM role credentials, do not attach AWS cloud credentials in Tower when relying on IAM roles to access the AWS API. While it may seem to make sense to attach your AWS cloud credential to your job template, doing so will force the use of your AWS credentials and will not “fall through” to use your IAM role credentials (this is due to the use of the boto library.)

10.4.2. Google Compute Engine ¶

Selecting this credential type enables synchronization of cloud inventory with Google Compute Engine.

Credentials - create GCE credential

Google Compute Engine credentials have several attributes that may be configured:

Service Account Email Address: The email address assigned to the Google Compute Engine service account.
Project: The GCE assigned identification. The GCE-assigned identification is required only if you intend to use a GCE credential for an inventory sync.
RSA Private Key: The PEM file associated with the service account email.

10.4.3. Insights ¶

Selecting this credential type enables synchronization of cloud inventory with Red Hat Insights.

Credentials - create Insights credential

Insights credentials consist of the Insights Username and Password, which is the user’s Red Hat Customer Portal Account username and password.

10.4.4. Machine ¶

Machine credentials enable Tower to invoke Ansible on hosts under your management. Just like using Ansible on the command line, you can specify the SSH username, optionally provide a password, an SSH key, a key password, or even have Tower prompt the user for their password at deployment time. They define ssh and user-level privilege escalation access for playbooks, and are used when submitting jobs to run playbooks on a remote host.

Credentials - create machine credential

Machine credentials have several attributes that may be configured:

Username: The username to be used for SSH authentication.
Password: The actual password to be used for SSH authentication. This password will be stored encrypted in the Tower database, if entered. Alternatively, you can configure Tower to ask the user for the password at launch time by selecting Prompt on launch. In these cases, a dialog opens when the job is launched, promoting the user to enter the password and password confirmation.
SSH Private Key: Copy or drag-and-drop the SSH private key for the machine credential.
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 will be stored encrypted in the Tower database, if entered. Alternatively, you can configure Tower to ask the user for the password at launch time by selecting Prompt on launch. In these cases, a dialog opens when the job is launched, prompting the user to enter the password and password confirmation.
Privilege Escalation Method: 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 | dzdo | pmrun.
- empty selection: Assigns no privilege escalation to this credential.
- sudo: Performs single commands with super user (root user) privileges
- su: Switches to the super user (root user) account (or to other user accounts)
- pbrun: Requests that an application or command be run in a controlled account and provides for advanced root privilege delegation and keylogging.
- pfexec: Executes commands with predefined process attributes, such as specific user or group IDs.
- dzdo: An enhanced version of sudo that uses RBAC information in an Centrify’s Active Directory service (see Centrify’s site on DZDO)
- pmrun: Requests that an application is run in a controlled account (refer to Privilege Manager for Unix 6.0)
- runas: Allows you to run as current user.
Privilege Escalation Username field is only seen if an option for privilege escalation is selected. Enter the username to use with escalation privileges on the remote system.
Privilege Escalation Password: field is only seen if an option for privilege escalation is selected. Enter the actual password to be used to authenticate the user via the selected privilege escalation type on the remote system. This password will be stored encrypted in the Tower database, if entered. Alternatively, you may configure Tower to ask the user for the password at launch time by selecting Prompt on launch. 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.

Warning

Credentials which are used in Scheduled Jobs must not be configured as “Prompt on launch”.

10.4.5. Microsoft Azure Classic (Deprecated)¶

Selecting this credential type enables synchronization of cloud inventory with Windows Azure Classic.

Credentials - create Azure Classic credential

Microsoft Azure credentials have several attributes to configure:

Subscription ID: The Subscription UUID for the Microsoft Azure Classic account.
Management Certificate: The PEM file that corresponds to the certificate you uploaded in the Microsoft Azure Classic console.

10.4.6. Microsoft Azure Resource Manager ¶

Selecting this credential type enables synchronization of cloud inventory with Microsoft Azure Resource Manager.

Credentials - create Azure credential

Microsoft Azure Resource Manager credentials have several attributes to configure:

Subscription ID: The Subscription UUID for the Microsoft Azure account.
Username: The username to use to connect to the Microsoft Azure account.
Password: The password to use to connect to the Microsoft Azure account.
Client ID: The Client ID for the Microsoft Azure account.
Client Secret: The Client Secret for the Microsoft Azure account.
Tenant ID: The Tenant ID for the Microsoft Azure account.

These fields are equivalent to the variables in the API. To pass service principal credentials, define the following variables:

AZURE_CLIENT_ID
AZURE_SECRET
AZURE_SUBSCRIPTION_ID
AZURE_TENANT

To pass an Active Directory username/password pair, define the following variables:

AZURE_AD_USER
AZURE_PASSWORD
AZURE_SUBSCRIPTION_ID

You can also pass credentials as parameters to a task within a playbook. The order of precedence is parameters, then environment variables, and finally a file found in your home directory.

To pass credentials as parameters to a task, use the following parameters for service principal credentials:

client_id
secret
subscription_id
tenant

Or, pass the following parameters for Active Directory username/password:

ad_user
password
subscription_id

10.4.7. Network ¶

Network credentials are used by Ansible networking modules to connect to and manage networking devices.

Credentials - create network credential

Network credentials have several attributes that may be configured:

Username: The username to use in conjunction with the network device.
Password: The password to use in conjunction with the network device.
SSH Private Key: Copy or drag-and-drop the actual SSH Private Key to be used to authenticate the user to the network via SSH.
Private Key Passphrase: The actual passphrase for the private key to be used to authenticate the user to the network via SSH.
Authorize: Select this from the Options field to add an Authorize Password which signs the RSA key - Authorize: Select this from the Options field to control whether or not to enter privileged mode.
If Authorize is checked, enter a password in the Authorize Password field to access privileged mode.

10.4.8. OpenStack ¶

Selecting this credential type enables synchronization of cloud inventory with OpenStack.

Credentials - create OpenStack credential

OpenStack credentials have several attributes that may be configured:

Username: The username to use to connect to OpenStack.
Password (API Key): The password or API key to use to connect to OpenStack.
Host (Authentication URL): The host to be used for authentication.
Project (Tenant Name): The Tenant name or Tenant ID used for OpenStack. This value is usually the same as the username.
Domain name: The FQDN to be used to connect to OpenStack.

If you are interested in using OpenStack Cloud Credentials, refer to Utilizing Cloud Credentials in this guide for more information, including a sample playbook.

10.4.9. Red Hat CloudForms ¶

Selecting this credential type enables synchronization of cloud inventory with Red Hat CloudForms.

Credentials - create Red Hat CloudForms credential

CloudForms have several attributes that may be configured:

CloudForms URL: The CloudForms URL or IP address to connect to.
Username: The username to use to connect to CloudForms.
Password: The password to use to connect to CloudForms.

Additional Resources:

Refer to Red Hat’s blog post series on Ansible Tower Integration in Red Hat CloudForms 4.1 at http://cloudformsblog.redhat.com/2016/07/22/ansible-tower-in-cloudforms/.

10.4.10. Red Hat Satellite 6 ¶

Selecting this credential type enables synchronization of cloud inventory with Red Hat Satellite 6.

Credentials - create Red Hat Satellite 6 credential

Satellite credentials have several attributes that may be configured:

Satellite 6 URL: The Satellite 6 URL or IP address to connect to.
Username: The username to use to connect to Satellite 6.
Password: The password to use to connect to Satellite 6.

10.4.11. Source Control ¶

SCM (source control) credentials are used with Projects to clone and update local source code repositories from a remote revision control system such as Git, Subversion, or Mercurial.

Credentials - create SCM credential

Source Control credentials have several attributes that may be configured:

Username: The username to use in conjunction with the source control system.
Password: The password to use in conjunction with the source control system.
SCM Private Key: Copy or drag-and-drop the actual SSH Private Key to be used to authenticate the user to the source control system via SSH.
Private Key Passphrase: If the SSH Private Key used is protected by a passphrase, you may configure a Key Passphrase for the private key.

Note

Source Control credentials cannot be configured as “Prompt on launch”.

10.4.12. Vault ¶

Selecting this credential type enables synchronization of inventory with Ansible Vault.

Credentials - create Vault credential

Vault credentials have only the Vault Password attribute that may be configured. You may configure Tower to ask the user for the password at launch time by selecting Prompt on launch. In these cases, a dialog opens when the job is launched, promoting the user to enter the password and password confirmation.

Warning

Credentials which are used in Scheduled Jobs must not be configured as “Prompt on launch”.

For more information about Ansible Vault, refer to: http://docs.ansible.com/ansible/playbooks_vault.html

10.4.13. VMware vCenter ¶

Selecting this credential type enables synchronization of inventory with VMware vCenter.

Credentials - create VMware credential

VMware credentials have several attributes that may be configured:

vCenter Host: The vCenter hostname or IP address to connect to.
Username: The username to use to connect to vCenter.
Password: The password to use to connect to vCenter.

Note

If the VMware guest tools are not running on the instance, VMware inventory sync may not return an IP address for that instance.